12-Network Management and Monitoring

HomeSupportConfigure & DeployConfiguration GuidesH3C Access Controllers Configuration Guides(R5228P01)-6W10212-Network Management and Monitoring
Table of Contents
Related Documents
01-Text
Title Size Download
01-Text 2.85 MB

Contents

Using ping, tracert, and system debugging· 1

Ping· 1

Using a ping command to test network connectivity· 1

Ping example· 1

Tracert 3

Prerequisites· 4

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

Tracert example· 4

System debugging· 5

Debugging information control switches· 6

Debugging a feature module· 6

Configuring NQA· 7

Overview·· 7

NQA operation· 7

Collaboration· 8

Threshold monitoring· 8

NQA configuration task list 9

Configuring the NQA server 9

Enabling the NQA client 9

Configuring NQA operations on the NQA client 10

NQA operation configuration task list 10

Configuring the ICMP echo operation· 10

Configuring the ICMP jitter operation· 11

Configuring the FTP operation· 12

Configuring the HTTP operation· 13

Configuring the UDP jitter operation· 14

Configuring the SNMP operation· 16

Configuring the TCP operation· 16

Configuring the UDP echo operation· 17

Configuring optional parameters for the NQA operation· 18

Configuring the collaboration feature· 18

Configuring threshold monitoring· 19

Configuring the NQA statistics collection feature· 21

Configuring the saving of NQA history records· 22

Scheduling the NQA operation on the NQA client 23

Configuring NQA templates on the NQA client 23

NQA template configuration task list 23

Configuring the ICMP template· 24

Configuring the TCP template· 25

Configuring the TCP half open template· 25

Configuring the UDP template· 26

Configuring the HTTP template· 27

Configuring the HTTPS template· 28

Configuring the FTP template· 30

Configuring the RADIUS template· 31

Configuring the SSL template· 31

Configuring optional parameters for the NQA template· 32

Displaying and maintaining NQA· 33

NQA configuration examples· 34

ICMP echo operation configuration example· 34

ICMP jitter operation configuration example· 35

FTP operation configuration example· 38

HTTP operation configuration example· 39

UDP jitter operation configuration example· 40

SNMP operation configuration example· 43

TCP operation configuration example· 44

UDP echo operation configuration example· 45

NQA collaboration configuration example· 46

ICMP template configuration example· 49

TCP template configuration example· 50

TCP half open template configuration example· 50

UDP template configuration example· 51

HTTP template configuration example· 52

HTTPS template configuration example· 53

FTP template configuration example· 53

RADIUS template configuration example· 54

SSL template configuration example· 55

Configuring NTP· 57

Overview·· 57

How NTP works· 57

NTP architecture· 58

Association modes· 59

NTP security· 61

Protocols and standards· 62

Configuration restrictions and guidelines· 62

Configuration task list 62

Enabling the NTP service· 63

Configuring NTP association modes· 63

Configuring NTP in client/server mode· 63

Configuring NTP in symmetric active/passive mode· 64

Configuring NTP in broadcast mode· 65

Configuring NTP in multicast mode· 65

Configuring access control rights· 66

Configuring NTP authentication· 67

Configuring NTP authentication in client/server mode· 67

Configuring NTP authentication in symmetric active/passive mode· 69

Configuring NTP authentication in broadcast mode· 70

Configuring NTP authentication in multicast mode· 71

Configuring NTP optional parameters· 73

Specifying the source interface for NTP messages· 73

Disabling an interface from processing NTP messages· 74

Configuring the maximum number of dynamic associations· 74

Setting a DSCP value for NTP packets· 75

Configuring the local clock as a reference source· 75

Displaying and maintaining NTP· 75

NTP configuration examples· 76

NTP client/server mode configuration example· 76

IPv6 NTP client/server mode configuration example· 77

NTP symmetric active/passive mode configuration example· 78

IPv6 NTP symmetric active/passive mode configuration example· 79

Configuration example for NTP authentication in client/server mode· 81

Configuring SNTP· 83

Configuration restrictions and guidelines· 83

Configuration task list 83

Enabling the SNTP service· 83

Specifying an NTP server for the device· 83

Configuring SNTP authentication· 84

Displaying and maintaining SNTP· 85

SNTP configuration example· 85

Configuring SNMP· 87

Overview·· 87

SNMP framework· 87

MIB and view-based MIB access control 87

SNMP operations· 88

Protocol versions· 88

Access control modes· 88

FIPS compliance· 89

Configuring SNMP basic parameters· 89

Configuring SNMPv1 or SNMPv2c basic parameters· 89

Configuring SNMPv3 basic parameters· 91

Configuring SNMP logging· 93

Configuring SNMP notifications· 94

Enabling SNMP notifications· 94

Configuring the SNMP agent to send notifications to a host 95

Displaying the SNMP settings· 96

SNMPv1/SNMPv2c configuration example· 97

Network requirements· 97

Configuration procedure· 97

Verifying the configuration· 98

SNMPv3 configuration example· 98

Network requirements· 98

Configuration procedure· 98

Verifying the configuration· 100

Configuring RMON· 101

Overview·· 101

RMON groups· 101

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

Protocols and standards· 103

Configuring the RMON statistics function· 103

Creating an RMON Ethernet statistics entry· 103

Creating an RMON history control entry· 103

Configuring the RMON alarm function· 104

Displaying and maintaining RMON settings· 105

RMON configuration examples· 105

Ethernet statistics group configuration example· 105

History group configuration example· 106

Alarm function configuration example· 108

Configuring NETCONF· 110

Overview·· 110

NETCONF structure· 110

NETCONF message format 111

How to use NETCONF· 112

Protocols and standards· 112

NETCONF configuration task list 113

Configuring NETCONF over SOAP· 113

Enabling NETCONF over SSH·· 114

Enabling NETCONF logging· 114

Establishing a NETCONF session· 114

Setting the NETCONF session idle timeout time· 115

Entering XML view·· 115

Exchanging capabilities· 115

Subscribing to event notifications· 116

Subscription procedure· 116

Example for subscribing to event notifications· 117

Locking/unlocking the configuration· 118

Locking the configuration· 118

Unlocking the configuration· 119

Example for locking the configuration· 119

Performing service operations· 120

Performing the get/get-bulk operation· 120

Performing the get-config/get-bulk-config operation· 122

Performing the edit-config operation· 122

All-module configuration data retrieval example· 123

Syslog configuration data retrieval example· 125

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

Example for changing the value of a parameter 127

Saving, rolling back, and loading the configuration· 128

Saving the configuration· 128

Rolling back the configuration based on a configuration file· 128

Rolling back the configuration based on a rollback point 129

Loading the configuration· 133

Example for saving the configuration· 133

Filtering data· 134

Table-based filtering· 134

Column-based filtering· 135

Example for filtering data with regular expression match· 137

Example for filtering data by conditional match· 139

Performing CLI operations through NETCONF· 140

Configuration procedure· 140

CLI operation example· 140

Retrieving NETCONF session information· 142

Terminating another NETCONF session· 143

Configuration procedure· 143

Configuration example· 143

Returning to the CLI 144

Appendix· 145

Appendix A Supported NETCONF operations· 145

Configuring EAA· 154

Overview·· 154

EAA framework· 154

Elements in a monitor policy· 155

EAA environment variables· 156

Command and hardware compatibility· 157

Configuring a user-defined EAA environment variable· 157

Configuring a monitor policy· 158

Configuration restrictions and guidelines· 158

Configuring a monitor policy from the CLI 158

Configuring a monitor policy by using Tcl 160

Suspending monitor policies· 161

Displaying and maintaining EAA settings· 161

EAA configuration examples· 162

CLI-defined policy configuration example· 162

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

Tcl-defined policy configuration example· 164

Monitoring and maintaining processes· 166

Overview·· 166

Command and hardware compatibility· 166

Displaying and maintaining processes· 166

Displaying and maintaining user processes· 166

Monitoring kernel threads· 167

Configuring kernel thread deadloop detection· 167

Configuring kernel thread starvation detection· 168

Displaying and maintaining kernel threads· 168

Configuring PoE· 170

Overview·· 170

Feature and hardware compatibility· 170

PoE configuration task list 171

Enabling PoE for a PI 171

Enabling nonstandard PD detection· 172

Configuring the maximum PI power 172

Configuring the PI priority policy· 173

Configuring PoE monitoring· 173

Configuring a PI by using a PoE profile· 174

Configuring a PoE profile· 174

Applying a PoE profile· 175

Displaying and maintaining PoE· 175

PoE configuration example· 176

Troubleshooting PoE· 177

Failure to set the priority of a PI to critical 177

Failure to apply a PoE profile to a PI 177

Configuring flow log· 178

Flow log configuration task list 179

Configuration prerequisites· 180

Specifying a flow log export destination· 180

Specifying a log host as the flow log export destination· 180

Specifying the information center as the flow log export destination· 181

Configuring the flow log version· 181

Specifying a source IP address for flow log packets· 181

Configuring the timestamp of flow logs· 181

Enabling load balancing for flow log entries· 182

Configuring flow log host groups· 182

About flow log host group· 182

Prerequisites· 182

Configuring an IPv4 flow log host group· 183

Configuring an IPv6 flow log host group· 183

Displaying and maintaining flow log· 183

Flow log configuration example· 183

Example: Configuring flow log export to a flow log host group· 185

Configuring the packet capture· 187

Overview·· 187

Packet capture modes· 187

Filter elements· 187

Building a capture filter 193

Building a display filter 194

Packet capture configuration task list 194

Configuring local packet capture on an AP radio· 195

Configuring remote packet capture on an AP radio· 195

Displaying and maintaining packet capture· 196

Packet capture configuration examples· 196

Local packet capture configuration example· 196

Remote packet capture configuration example· 197

Configuring the information center 199

Overview·· 199

Log types· 199

Log levels· 199

Log destinations· 200

Default output rules for logs· 200

Default output rules for diagnostic logs· 200

Default output rules for security logs· 201

Default output rules for hidden logs· 201

Default output rules for trace logs· 201

Default output rules for custom logs· 201

Log formats· 201

Command and hardware compatibility· 204

Information center configuration task list 204

Outputting logs to the console· 204

Outputting logs to the monitor terminal 205

Outputting logs to log hosts· 206

Outputting common logs to log hosts· 206

Outputting custom logs to log hosts· 206

Outputting logs to the log buffer 207

Saving logs to the log file· 208

Saving security logs to the security log file· 209

Saving diagnostic logs to the diagnostic log file· 210

Setting the minimum storage period for logs· 210

Enabling synchronous information output 211

Enabling duplicate log suppression· 211

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

Enabling SNMP notifications for system logs· 212

Displaying and maintaining information center 212

Information center configuration examples· 213

Configuration example for outputting logs to the console· 213

Configuration example for outputting logs to a UNIX log host 214

Configuration example for outputting logs to a Linux log host 215

Configuring port mirroring· 217

Overview·· 217

Terminology· 217

Local port mirroring implementation· 217

Local port mirroring configuration task list 218

Creating a local mirroring group· 218

Configuring source ports for the local mirroring group· 219

Configuration restrictions and guidelines· 219

Configuring source ports in system view·· 219

Configuring source ports in interface view·· 219

Configuring the monitor port for the local mirroring group· 219

Configuration restrictions and guidelines· 220

Configuring the monitor port in system view·· 220

Configuring the monitor port in interface view·· 220

Displaying and maintaining port mirroring· 220

Local port mirroring configuration example· 221

Index· 222

 


Using ping, tracert, and system debugging

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

Ping

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

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

Using a ping command to test network connectivity

Execute ping commands in any view.

 

Task

Command

Determine if an address in an IP network is reachable.

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

·     For IPv4 networks:
ping [ ip ] [ -a source-ip | -c count | -f | -h ttl | -i interface-type interface-number | -m interval | -n | -p pad | -q | -r | -s packet-size | -t timeout | -tos tos | -v ] * host

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

 

Ping example

Network requirements

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

Figure 1 Network diagram

 

Configuration procedure

# Use the ping command on the AC to test connectivity to Device B.

Ping 1.1.2.2 (1.1.2.2): 56 data bytes, press CTRL_C to break

56 bytes from 1.1.2.2: icmp_seq=0 ttl=254 time=2.137 ms

56 bytes from 1.1.2.2: icmp_seq=1 ttl=254 time=2.051 ms

56 bytes from 1.1.2.2: icmp_seq=2 ttl=254 time=1.996 ms

56 bytes from 1.1.2.2: icmp_seq=3 ttl=254 time=1.963 ms

56 bytes from 1.1.2.2: icmp_seq=4 ttl=254 time=1.991 ms

 

--- Ping statistics for 1.1.2.2 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 1.963/2.028/2.137/0.062 ms

The output shows that:

·     The AC sends five ICMP packets to Device B and the AC receives five ICMP packets.

·     No ICMP packet is lost.

·     The route is reachable.

# Get detailed information about routes from the AC to Device B.

<AC> ping -r 1.1.2.2

Ping 1.1.2.2 (1.1.2.2): 56 data bytes, press CTRL_C to break

56 bytes from 1.1.2.2: icmp_seq=0 ttl=254 time=4.685 ms

RR:      1.1.2.1

         1.1.2.2

         1.1.1.2

         1.1.1.1

56 bytes from 1.1.2.2: icmp_seq=1 ttl=254 time=4.834 ms  (same route)

56 bytes from 1.1.2.2: icmp_seq=2 ttl=254 time=4.770 ms  (same route)

56 bytes from 1.1.2.2: icmp_seq=3 ttl=254 time=4.812 ms  (same route)

56 bytes from 1.1.2.2: icmp_seq=4 ttl=254 time=4.704 ms  (same route)

 

--- Ping statistics for 1.1.2.2 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 4.685/4.761/4.834/0.058 ms

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

1.     The source device (the AC) sends an ICMP echo request to the destination device (Device B) with the RR option blank.

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

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

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

5.     Upon receiving the reply, the source device adds the IP address of its inbound interface (1.1.1.1) to the RR option. The detailed information of routes from the AC to Device B is formatted as: 1.1.1.1 <-> {1.1.1.2; 1.1.2.1} <-> 1.1.2.2.

Tracert

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

Figure 2 Tracert operation

 

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

1.     The source device sends a UDP packet with a TTL value of 1 to the destination device. The destination UDP port is not used by any application on the destination device.

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

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

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

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

6.     The source device determines that:

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

?     The path to the destination device is 1.1.1.2 to 1.1.2.2 to 1.1.3.2.

Prerequisites

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

For an IPv4 network:

·     Enable sending of ICMP timeout packets on the intermediate devices (devices between the source and destination devices). If the intermediate devices are H3C devices, execute the ip ttl-expires enable command on the devices. For more information about this command, see Layer 3—IP Services Command Reference.

·     Enable sending of ICMP destination unreachable packets on the destination device. If the destination device is an H3C device, execute the ip unreachables enable command. For more information about this command, see Layer 3—IP Services Command Reference.

For an IPv6 network:

·     Enable sending of ICMPv6 timeout packets on the intermediate devices (devices between the source and destination devices). If the intermediate devices are H3C devices, execute the ipv6 hoplimit-expires enable command on the devices. For more information about this command, see Layer 3—IP Services Command Reference.

·     Enable sending of ICMPv6 destination unreachable packets on the destination device. If the destination device is an H3C device, execute the ipv6 unreachables enable command. For more information about this command, see Layer 3—IP Services Command Reference.

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

Execute tracert commands in any view.

 

Task

Command

 

Display the routes from source to destination.

·     For IPv4 networks:
tracert [ -a source-ip | -f first-ttl | -m max-ttl | -p port | -q packet-number | -t tos | -w timeout ] * host

·     For IPv6 networks:
tracert ipv6 [ -f first-hop | -m max-hops | -p port | -q packet-number |
-t traffic-class | -w timeout ] * host

 

Tracert example

Network requirements

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

Test the network connectivity between the AC and Device B. If they cannot reach each other, locate the failed nodes in the network.

Figure 3 Network diagram

 

Configuration procedure

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

2.     Configure a static route on the AC.

<AC> system-view

[AC] ip route-static 0.0.0.0 0.0.0.0 1.1.1.2

[AC] quit

3.     Use the ping command to test connectivity between the AC and Device B.

<AC> ping 1.1.2.2

Ping 1.1.2.2(1.1.2.2): 56 -data bytes, press CTRL_C to break

Request time out

Request time out

Request time out

Request time out

Request time out

 

--- Ping statistics for 1.1.2.2 ---

5 packet(s) transmitted,0 packet(s) received,100.0% packet loss

The output shows that the AC and Device B cannot reach each other.

4.     Use the tracert command to identify failed nodes:

# Enable sending of ICMP timeout packets on Device A.

<DeviceA> system-view

[DeviceA] ip ttl-expires enable

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

<DeviceB> system-view

[DeviceB] ip unreachables enable

# Execute the tracert command on the AC.

<AC> tracert 1.1.2.2

traceroute to 1.1.2.2 (1.1.2.2) 30 hops at most,40 bytes each packet, press CTRL_C to break

 1  1.1.1.2 (1.1.1.2) 1 ms 2 ms 1 ms

 2  * * *

 3  * * *

 4  * * *

 5

<AC>

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

5.     To identify the cause of the problem, execute the following commands on the AC and Device B:

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

?     Execute the display ip routing-table command to verify that the devices have a route to each other.

System debugging

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

Debugging information control switches

The following switches control the display of debugging information:

·     Module debugging switchControls whether to generate the module-specific debugging information.

·     Screen output switch—Controls whether to display the debugging information on a certain screen. Use terminal monitor and terminal logging level commands to turn on the screen output switch. For more information about these two commands, see Network Management and Monitoring Command Reference.

As shown in Figure 4, assume that the device can provide debugging for the three modules 1, 2, and 3. The debugging information can be output on a terminal only when both the module debugging switch and the screen output switch are turned on.

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

Figure 4 Relationship between the module and screen output switch

 

Debugging a feature module

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

To debug a feature module:

 

Step

Command

Remarks

1.     Enable debugging for a module in user view.

debugging module-name [ option ]

By default, debugging is disabled for modules.

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

display debugging [ module-name ]

N/A

 

 


Configuring NQA

Overview

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

·     ICMP echo.

·     ICMP jitter.

·     FTP.

·     HTTP.

·     SNMP.

·     TCP.

·     UDP echo.

·     UDP jitter.

As shown in Figure 5, the NQA source device (NQA client) sends data to the NQA destination device by simulating IP services and applications to measure network performance. The obtained performance metrics include the packet loss, application performance, and server response time.

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

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

Figure 5 Network diagram

 

NQA operation

The following describes how NQA performs different types of operations:

·     A TCP operation sets up a connection.

·     An ICMP jitter or UDP jitter operation sends a number of probe packets. The number of probe packets is set by using the probe packet-number command.

·     An FTP operation uploads or downloads a file.

·     An HTTP operation gets a Web page.

·     An ICMP echo operation sends an ICMP echo request.

·     A UDP echo operation sends a UDP packet.

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

Collaboration

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

Figure 6 Collaboration

 

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

1.     NQA monitors the reachability to 192.168.0.88.

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

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

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

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

Threshold monitoring

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

Table 1 describes the relationships between performance metrics and NQA operation types.

Table 1 Performance metrics and NQA operation types

Performance metric

NQA operation types that can gather the metric

Probe duration

ICMP echo, FTP, HTTP, SNMP, TCP, UDP echo

Number of probe failures

ICMP echo, FTP, HTTP, SNMP, TCP, UDP echo

Round-trip time

ICMP jitter and UDP jitter

Number of discarded packets

ICMP jitter and UDP jitter

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

ICMP jitter and UDP jitter

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

ICMP jitter and UDP jitter

 

NQA configuration task list

Tasks at a glance

Remarks

Configuring the NQA server

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

(Required.) Enabling the NQA client

N/A

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

·     Configuring NQA operations on the NQA client

·     Configuring NQA templates on the NQA client

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

 

Configuring the NQA server

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

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

To configure the NQA server:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable the NQA server.

nqa server enable

By default, the NQA server is disabled.

3.     Configure a TCP or UDP listening service.

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

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

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

 

Enabling the NQA client

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable the NQA client.

nqa agent enable

By default, the NQA client is enabled.

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

 

Configuring NQA operations on the NQA client

NQA operation configuration task list

Tasks at a glance

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

·     Configuring the ICMP echo operation

·     Configuring the ICMP jitter operation

·     Configuring the FTP operation

·     Configuring the HTTP operation

·     Configuring the UDP jitter operation

·     Configuring the SNMP operation

·     Configuring the TCP operation

·     Configuring the UDP echo operation

(Optional.) Configuring optional parameters for the NQA operation

(Optional.) Configuring the collaboration feature

(Optional.) Configuring threshold monitoring

(Optional.) Configuring the NQA statistics collection feature

(Optional.) Configuring the saving of NQA history records

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

 

Configuring the ICMP echo operation

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

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

To configure the ICMP echo operation:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

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

type icmp-echo

N/A

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

·     IPv4 address:
destination ip ip-address

·     IPv6 address:
destination ipv6 ipv6-address

By default, no destination IP address is specified.

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

data-size size

The default setting is 100 bytes.

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

data-fill string

The default payload fill string is the hexadecimal number 00010203040506070809.

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

out interface interface-type interface-number

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

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

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

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

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

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

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

The specified source interface must be up.

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

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

·     IPv4 address:
next-hop ip ip-address

·     IPv6 address:
next-hop ipv6 ipv6-address

By default, no next hop IP address is configured.

 

Configuring the ICMP jitter operation

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

The ICMP jitter operation works as follows:

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

2.     The destination device time stamps each packet it receives, and then sends the packet back to the NQA client.

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

The display nqa history command does not display the results or statistics of the ICMP jitter operation. To view the results or statistics of the operation, use the display nqa result or display nqa statistics command.

To configure the ICMP jitter operation:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

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

type icmp-jitter

N/A

4.     Specify the destination address for ICMP packets.

destination ip ip-address

By default, no destination IP address is specified.

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

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

source ip ip-address

By default, the source IP address of ICMP packets is the primary IP address of their output interface.

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

6.     (Optional.) Set the number of ICMP packets sent per probe.

probe packet-number

packet-number

The default setting is 10.

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

probe packet-interval interval

The default setting is 20 milliseconds.

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

probe packet-timeout timeout

The default setting is 3000 milliseconds.

 

Configuring the FTP operation

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

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

·     When you perform the put operation with the filename command configured, make sure the file exists on the NQA client.

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

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

·     Use a small file for the FTP operation. A big file might result in transfer failure because of timeout, or might affect other services because of the amount of network bandwidth it occupies.

To configure the FTP operation:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.     Specify the FTP type and enter its view.

type ftp

N/A

4.     Specify the URL of the destination FTP server.

url url

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

Enter the URL in one of the following formats:

·     ftp://host/filename.

·     ftp://host:port/filename.

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

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

source ip ip-address

By default, no source IP address is specified.

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

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

operation { get | put }

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

7.     Specify an FTP login username.

username username

By default, no FTP login username is configured.

8.     Specify an FTP login password.

password { cipher | simple } password

By default, no FTP login password is configured.

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

filename file-name

By default, no file is specified.

This step is required if you perform the put operation.

10.     Set the data transmission mode.

mode { active | passive }

The default mode is active.

 

Configuring the HTTP operation

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

To configure an HTTP operation:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.     Specify the HTTP type and enter its view.

type http

N/A

4.     Specify the URL of the destination HTTP server.

url url

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

Enter the URL in one of the following formats:

·     http://host/resource.

·     http://host:port/resource.

5.     Specify an HTTP login username.

username username

By default, no HTTP login username is specified.

6.     Specify an HTTP login password.

password { cipher | simple } password

By default, no HTTP login password is specified.

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

source ip ip-address

By default, no source IP address is specified.

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

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

operation { get | post | raw }

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

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

9.     Specify the HTTP version.

version { v1.0 | v1.1 }

By default, HTTP 1.0 is used.

10.     (Optional.) Enter raw request view.

raw-request

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

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

Enter or paste the content.

By default, no contents are specified.

This step is required for the raw operation.

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

quit

N/A

 

Configuring the UDP jitter operation

CAUTION:

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

 

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

The UDP jitter operation works as follows:

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

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

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

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

To configure a UDP jitter operation:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

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

type udp-jitter

N/A

4.     Specify the destination address of UDP packets.

destination ip ip-address

By default, no destination IP address is specified.

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

5.     Specify the destination port of UDP packets.

destination port port-number

By default, no destination port number is specified.

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

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

source port port-number

By default, no source port number is specified.

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

data-size size

The default setting is 100 bytes.

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

data-fill string

The default payload fill string is the hexadecimal number 00010203040506070809.

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

probe packet-number

packet-number

The default setting is 10.

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

probe packet-interval packet-interval

The default setting is 20 milliseconds.

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

probe packet-timeout packet-timeout

The default setting is 3000 milliseconds.

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

source ip ip-address

By default, no source IP address is specified.

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

13.     (Optional.) Specify the source port for UDP packets.

source port port-number

By default, no source port is specified.

 

 

NOTE:

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

 

Configuring the SNMP operation

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

To configure the SNMP operation:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.     Specify the SNMP type and enter its view.

type snmp

N/A

4.     Specify the destination address of SNMP packets.

destination ip ip-address

By default, no destination IP address is specified.

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

source port port-number

By default, no source port number is specified.

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

source ip ip-address

By default, no source IP address is specified.

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

 

Configuring the TCP operation

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

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

To configure the TCP operation:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.     Specify the TCP type and enter its view.

type tcp

N/A

4.     Specify the destination address of TCP packets.

destination ip ip-address

By default, no destination IP address is specified.

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

5.     Specify the destination port of TCP packets.

destination port port-number

By default, no destination port number is configured.

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

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

source ip ip-address

By default, no source IP address is specified.

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

 

Configuring the UDP echo operation

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

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

To configure the UDP echo operation:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

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

type udp-echo

N/A

4.     Specify the destination address of UDP packets.

destination ip ip-address

By default, no destination IP address is specified.

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

5.     Specify the destination port of UDP packets.

destination port port-number

By default, no destination port number is specified.

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

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

data-size size

The default setting is 100 bytes.

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

data-fill string

The default payload fill string is the hexadecimal number 00010203040506070809.

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

source port port-number

By default, no source port number is specified.

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

source ip ip-address

By default, no source IP address is specified.

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

 

Configuring optional parameters for the NQA operation

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

The parameter settings take effect only on the current operation.

To configure optional parameters for an NQA operation:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

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

type { ftp | http | icmp-echo | icmp-jitter | snmp | tcp | udp-echo | udp-jitter  }

N/A

4.     Configure a description.

description text

By default, no description is configured.

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

frequency interval

The default setting is 0 milliseconds. Only one operation is performed.

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

6.     Specify the probe times.

probe count times

By default, the NQA client performs one probe to the destination per operation.

7.     Set the probe timeout time.

probe timeout timeout

The default setting is 3000 milliseconds.

This command is not available for ICMP jitter or UDP jitter operations.

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

ttl value

The default setting is 20.

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

tos value

The default setting is 0.

10.     Enable the routing table bypass feature.

route-option bypass-route

By default, the routing table bypass feature is disabled.

 

Configuring the collaboration feature

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

To configure the collaboration feature:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

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

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

The collaboration feature is not available for ICMP jitter or UDP jitter operations.

4.     Configure a reaction entry.

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

By default, no reaction entry is configured.

5.     Exit to system view.

quit

N/A

6.     Associate Track with NQA.

See High Availability Configuration Guide.

N/A

7.     Associate Track with an application module.

See High Availability Configuration Guide.

N/A

 

Configuring threshold monitoring

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

Threshold types

An NQA operation supports the following threshold types:

·     average—If the average value for the monitored performance metric either exceeds the upper threshold or goes below the lower threshold, a threshold violation occurs.

·     accumulateIf the total number of times that the monitored performance metric is out of the specified value range reaches or exceeds the specified threshold, a threshold violation occurs.

·     consecutiveIf the number of consecutive times that the monitored performance metric is out of the specified value range reaches or exceeds the specified threshold, a threshold violation occurs.

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

Triggered actions

The following actions might be triggered:

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

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

·     trigger-only—NQA displays results on the terminal screen, and meanwhile triggers other modules for collaboration.

Reaction entry

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

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

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

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

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

Configuration procedure

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

To configure threshold monitoring:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.     Enter NQA operation view.

type { ftp | http | icmp-echo | icmp-jitter | snmp | tcp | udp-echo | udp-jitter }

N/A

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

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

By default, no traps are sent to the NMS.

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

5.     Configure threshold monitoring.

·     Monitor the operation duration (not supported in the ICMP jitter, UDP jitter, or UDP tracert operations):
reaction item-number checked-element probe-duration threshold-type { accumulate accumulate-occurrences | average | consecutive consecutive-occurrences } threshold-value upper-threshold lower-threshold [ action-type { none | trap-only } ]

·     Monitor failure times (not supported in the ICMP jitter, UDP jitter, or UDP tracert operations):
reaction item-number checked-element probe-fail threshold-type { accumulate accumulate-occurrences | consecutive consecutive-occurrences } [ action-type { none | trap-only } ]

·     Monitor the round-trip time (only for the ICMP jitter and UDP jitter operations):
reaction item-number checked-element rtt threshold-type { accumulate accumulate-occurrences | average } threshold-value upper-threshold lower-threshold [ action-type { none | trap-only } ]

·     Monitor packet loss (only for the ICMP jitter and UDP jitter operations):
reaction item-number checked-element packet-loss threshold-type accumulate accumulate-occurrences [ action-type { none | trap-only } ]

·     Monitor the one-way jitter (only for the ICMP jitter and UDP jitter operations):
reaction item-number checked-element { jitter-ds | jitter-sd } threshold-type { accumulate accumulate-occurrences | average } threshold-value upper-threshold lower-threshold [ action-type { none | trap-only } ]

·     Monitor the one-way delay (only for the ICMP jitter and UDP jitter operations):
reaction item-number checked-element { owd-ds | owd-sd } threshold-value upper-threshold lower-threshold

N/A

 

Configuring the NQA statistics collection feature

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

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

To configure the NQA statistics collection feature:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

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

type { ftp | http | icmp-echo | icmp-jitter | snmp | tcp | udp-echo | udp-jitter }

The UDP tracert and path quality analysis operations do not support the NQA statistics collection feature.

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

statistics interval interval

The default setting is 60 minutes.

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

statistics max-group number

The default setting is two groups.

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

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

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

statistics hold-time hold-time

The default setting is 120 minutes.

A statistics group is deleted when its hold time expires.

 

Configuring the saving of NQA history records

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.     Enter NQA operation type view.

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

The ICMP jitter and UDP jitter operations do not support saving history records.

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

history-record enable

By default, this feature is disabled.

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

history-record keep-time keep-time

The default setting is 120 minutes.

A record is deleted when its lifetime is reached.

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

history-record number number

The default setting is 50.

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

7.     (Optional.) Display NQA history records.

display nqa history

N/A

 

Scheduling the NQA operation on the NQA client

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

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

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

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

To schedule the NQA operation on the NQA client:

 

Step

Command

1.     Enter system view.

system-view

2.     Specify the scheduling parameters for an NQA operation.

nqa schedule admin-name operation-tag start-time { hh:mm:ss [ yyyy/mm/dd | mm/dd/yyyy ] | now } lifetime { lifetime | forever } [ recurring ]

 

Configuring NQA templates on the NQA client

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

NQA template supports the FTP, HTTP, HTTPS, ICMP, RADIUS, SSL, TCP, TCP half open, and UDP operation types.

Some operation parameters for an NQA template can be specified by the template configuration or the feature that uses the template. When both are specified, the parameters in the template configuration take effect. For example, the server load balancing uses the NQA ICMP template for health monitoring. If the destination IP address in the template is different from the real server address, the destination IP address in the template takes effect.

NQA template configuration task list

Tasks at a glance

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

·     Configuring the ICMP template

·     Configuring the TCP template

·     Configuring the TCP half open template

·     Configuring the UDP template

·     Configuring the HTTP template

·     Configuring the HTTPS template

·     Configuring the FTP template

·     Configuring the RADIUS template

·     Configuring the SSL template

(Optional.) Configuring optional parameters for the NQA template

 

Configuring the ICMP template

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

To configure the ICMP template:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create an ICMP template and enter its view.

nqa template icmp name

By default, no ICMP templates exist.

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

·     IPv4 address:
destination ip ip-address

·     IPv6 address:
destination ipv6 ipv6-address

By default, no destination IP address is configured.

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

data-size size

The default setting is 100 bytes.

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

data-fill string

The default payload fill string is the hexadecimal number 00010203040506070809.

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

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

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

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

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

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

The specified source interface must be up.

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

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

·     IPv4 address:
next-hop ip ip-address

·     IPv6 address:
next-hop ipv6 ipv6-address

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

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

reaction trigger per-probe

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

If you execute the reaction trigger per-probe command and the reaction trigger probe-pass or reaction trigger probe-fail command, the most recent configuration takes effect.

 

Configuring the TCP template

A feature that uses the TCP template performs the TCP operation to test whether the NQA client can establish a TCP connection to a specific port on the server.

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

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

To configure the TCP template:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create a TCP template and enter its view.

nqa template tcp name

By default, no TCP templates exist.

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

·     IPv4 address:
destination ip ip-address

·     IPv6 address:
destination ipv6 ipv6-address

By default, no destination address is specified.

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

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

destination port port-number

By default, no destination port number is specified.

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

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

data-fill string

The default payload fill string is the hexadecimal number 00010203040506070809.

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

·     IPv4 address:
source ip
ip-address

·     IPv6 address:
source ip
v6 ipv6-address

By default, no source IP address is specified.

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

7.     (Optional.) Configure the expected data.

expect data expression [ offset number ]

By default, no expected data is configured.

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

 

Configuring the TCP half open template

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

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

To configure the TCP half open template:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

nqa template tcphalfopen name

By default, no TCP half open templates exist.

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

·     IPv4 address:
destination ip ip-address

·     IPv6 address:
destination ipv6 ipv6-address

By default, no destination address is specified.

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

·     IPv4 address:
source ip
ip-address

·     IPv6 address:
source ip
v6 ipv6-address

By default, no source IP address is specified.

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

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

·     IPv4 address:
next-hop ip ip-address

·     IPv6 address:
next-hop ipv6 ipv6-address

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

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

reaction trigger per-probe

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

If you execute the reaction trigger per-probe command and the reaction trigger probe-pass or reaction trigger probe-fail command, the most recent configuration takes effect.

 

Configuring the UDP template

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

·     Reachability of a specific port on the NQA server.

·     Availability of the requested service on the NQA server.

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

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

To configure the UDP template:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create a UDP template and enter its view.

nqa template udp name

By default, no UDP templates exist.

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

·     IPv4 address:
destination ip ip-address

·     IPv6 address:
destination ipv6 ipv6-address

By default, no destination address is specified.

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

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

destination port port-number

By default, no destination port number is specified.

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

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

data-fill string

The default payload fill string is the hexadecimal number 00010203040506070809.

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

data-size size

The default setting is 100 bytes.

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

·     IPv4 address:
source ip
ip-address

·     IPv6 address:
source ip
v6 ipv6-address

By default, no source IP address is specified.

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

8.     (Optional.) Configure the expected data.

expect data expression [ offset number ]

By default, no expected data is configured.

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

 

Configuring the HTTP template

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

The expected data is checked only when the expected data is configured and the HTTP response contains the Content-Length field in the HTTP header.

The status code of the HTTP packet is a three-digit field in decimal notation, and it includes the status information for the HTTP server. The first digit defines the class of response.

Configure the HTTP server before you perform the HTTP operation.

To configure the HTTP template:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create an HTTP template and enter its view.

nqa template http name

By default, no HTTP templates exist.

3.     Specify the URL of the destination HTTP server.

url url

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

Enter the URL in one of the following formats:

·     http://host/resource.

·     http://host:port/resource.

4.     Specify an HTTP login username.

username username

By default, no HTTP login username is specified.

5.     Specify an HTTP login password.

password { cipher | simple } password

By default, no HTTP login password is specified.

6.     (Optional.) Specify the HTTP version.

version { v1.0 | v1.1 }

By default, HTTP 1.0 is used.

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

operation { get | post | raw }

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

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

8.     (Optional.) Enter raw request view.

raw-request

This step is required for the raw operation.

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

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

N/A

This step is required for the raw operation.

By default, the HTTP request content is not specified.

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

quit

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

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

·     IPv4 address:
source ip
ip-address

·     IPv6 address:
source ip
v6 ipv6-address

By default, no source IP address is specified.

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

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

expect status status-list

By default, no expected status code is configured.

13.     (Optional.) Configure the expected data.

expect data expression [ offset number ]

By default, no expected data is configured.

 

Configuring the HTTPS template

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

The expected data is checked only when the expected data is configured and the HTTPS response contains the Content-Length field in the HTTPS header.

The status code of the HTTPS packet is a three-digit field in decimal notation, and it includes the status information for the HTTPS server. The first digit defines the class of response.

Before you perform the HTTPS operation, configure the HTTPS server and the SSL client policy for the SSL client. For information about configuring SSL client policies, see Security Configuration Guide.

To configure the HTTPS template:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create an HTTPS template and enter its view.

nqa template https name

By default, no HTTPS templates exist.

3.     Specify the URL of the destination HTTPS server.

url url

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

Enter the URL in one of the following formats:

·     https://host/resource.

·     https://host:port/resource.

4.     Specify an HTTPS login username.

username username

By default, no HTTPS login username is specified.

5.     Specify an HTTPS login password.

password { cipher | simple } password

By default, no HTTPS login password is specified.

6.     Specify an SSL client policy.

ssl-client-policy policy-name

By default, no SSL client policy is specified.

7.     (Optional.) Specify the HTTPS version.

version { v1.0 | v1.1 }

By default, HTTPS 1.0 is used.

8.     (Optional.) Specify the HTTPS operation type.

operation { get | post | raw }

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

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

9.     (Optional.) Enter raw request view.

raw-request

This step is required for the raw operation.

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

10.     (Optional.) Enter or paste the content of the HTTPS request for the HTTPS operation.

N/A

This step is required for the raw operation.

By default, the HTTPS request content is not specified.

11.     (Optional.) Exit to HTTPS template view.

quit

The system automatically saves the configuration in raw request view before it exits to HTTPS template view.

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

·     IPv4 address:
source ip
ip-address

·     IPv6 address:
source ip
v6 ipv6-address

By default, no source IP address is specified.

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

13.     (Optional.) Configure the expected data.

expect data expression [ offset number ]

By default, no expected data is configured.

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

expect status status-list

By default, no expected status code is configured.

 

Configuring the FTP template

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

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

To configure the FTP template:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create an FTP template and enter its view.

nqa template ftp name

By default, no FTP templates exist.

3.     Specify the URL of the destination FTP server.

url url

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

Enter the URL in one of the following formats:

·     ftp://host/filename.

·     ftp://host:port/filename.

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

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

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

operation { get | put }

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

5.     Specify an FTP login username.

username username

By default, no FTP login username is specified.

6.     Specify an FTP login password.

password { cipher | simple } password

By default, no FTP login password is specified.

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

filename filename

This step is required if you perform the put operation.

This configuration does not take effect for the get operation.

By default, no file is specified.

8.     Set the data transmission mode.

mode { active | passive }

The default mode is active.

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

·     IPv4 address:
source ip
ip-address

·     IPv6 address:
source ip
v6 ipv6-address

By default, no source IP address is specified.

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

 

Configuring the RADIUS template

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

The RADIUS operation authentication workflow is as follows:

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

2.     The RADIUS server authenticates the username and password.

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

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

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

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

To configure the RADIUS template:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create a RADIUS template and enter its view.

nqa template radius name

By default, no RADIUS templates exist.

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

·     IPv4 address:
destination ip ip-address

·     IPv6 address:
destination ipv6 ipv6-address

By default, no destination IP address is configured.

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

destination port port-number

By default, the destination port number is 1812.

5.     Specify a username.

username username

By default, no username is specified.

6.     Specify a password.

password { cipher | simple } password

By default, no password is specified.

7.     Specify a shared key for secure RADIUS authentication.

key { cipher | simple } string

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

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

·     IPv4 address:
source ip
ip-address

·     IPv6 address:
source ipv6
ipv6-address

By default, no source IP address is specified.

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

 

Configuring the SSL template

A feature that uses the SSL template performs the SSL operation to measure the time required to establish an SSL connection to an SSL server.

Before you configure the SSL template, configure the SSL client policy. For information about configuring SSL client policies, see Security Configuration Guide.

To configure the SSL template:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create an SSL template and enter its view.

nqa template ssl name

By default, no SSL templates exist.

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

·     IPv4 address:
destination ip ip-address

·     IPv6 address:
destination ipv6 ipv6-address

By default, no destination IP address is configured.

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

destination port port-number

By default, the destination port number is not specified.

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

·     IPv4 address:
source ip
ip-address

·     IPv6 address:
source ipv6
ipv6-address

By default, no source IP address is specified.

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

6.     Specify an SSL client policy.

ssl-client-policy policy-name

By default, no SSL client policy is specified.

 

Configuring optional parameters for the NQA template

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

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

To configure optional parameters for an NQA template:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create an NQA template and enter its view.

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

By default, no NQA templates exist.

3.     Configure a description.

description text

By default, no description is configured.

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

frequency interval

The default setting is 5000 milliseconds.

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

5.     Set the probe timeout time.

probe timeout timeout

The default setting is 3000 milliseconds.

6.     Set the TTL for probe packets.

ttl value

The default setting is 20.

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

tos value

The default setting is 0.

8.     Set the number of consecutive successful probes that lead to a successful operation.

reaction trigger probe-pass count

The default setting is 3.

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

9.     Set the number of consecutive probe failures that lead to an operation failure.

reaction trigger probe-fail count

The default setting is 3.

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

 

Displaying and maintaining NQA

Execute display commands in any view.

 

Task

Command

Display history records of NQA operations.

display nqa history [ admin-name operation-tag ]

Display the current monitoring results of reaction entries.

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

Display the most recent result of the NQA operation.

display nqa result [ admin-name operation-tag ]

Display NQA statistics.

display nqa statistics [ admin-name operation-tag ]

Display NQA server status.

display nqa server status

 

NQA configuration examples

ICMP echo operation configuration example

Network requirements

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

Figure 7 Network diagram

 

Configuration procedure

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

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

# Create an ICMP echo operation.

<AC> system-view

[AC] nqa entry admin test1

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

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

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

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

[AC-nqa-admin-test1-icmp-echo] next-hop ip 10.1.1.2

# Configure the ICMP echo operation to perform 10 probes.

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

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

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

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

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

# Enable saving history records.

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

# Set the maximum number of history records to 10.

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

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

# Start the ICMP echo operation.

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

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

[AC] undo nqa schedule admin test1

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

[AC] display nqa result admin test1

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

    Send operation times: 10             Receive response times: 10

    Min/Max/Average round trip time: 2/5/3

    Square-Sum of round trip time: 96

    Last succeeded probe time: 2011-08-23 15:00:01.2

  Extended results:

    Packet loss ratio: 0%

    Failures due to timeout: 0

    Failures due to internal error: 0

    Failures due to other errors: 0

# Display the history records of the ICMP echo operation.

[AC] display nqa history admin test1

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

  Index      Response     Status           Time

  370        3            Succeeded        2007-08-23 15:00:01.2

  369        3            Succeeded        2007-08-23 15:00:01.2

  368        3            Succeeded        2007-08-23 15:00:01.2

  367        5            Succeeded        2007-08-23 15:00:01.2

  366        3            Succeeded        2007-08-23 15:00:01.2

  365        3            Succeeded        2007-08-23 15:00:01.2

  364        3            Succeeded        2007-08-23 15:00:01.1

  363        2            Succeeded        2007-08-23 15:00:01.1

  362        3            Succeeded        2007-08-23 15:00:01.1

  361        2            Succeeded        2007-08-23 15:00:01.1

The output shows that the packets sent by the AC can reach Device A through Device B. No packet loss occurs during the operation. The minimum, maximum, and average round-trip times are 2, 5, and 3 milliseconds, respectively.

ICMP jitter operation configuration example

Network requirements

As shown in Figure 8, configure an ICMP jitter operation to test the jitter between the AC and the device.

Figure 8 Network diagram

 

Configuration procedure

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

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

3.     Configure the AC:

# Create an ICMP jitter operation.

<AC> system-view

[AC] nqa entry admin test1

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

# Specify 10.2.2.2 as the destination address for the operation.

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

# Configure the operation to repeat every 1000 milliseconds.

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

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

# Start the ICMP jitter operation.

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

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

[AC] undo nqa schedule admin test1

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

[AC] display nqa result admin test1

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

    Send operation times: 10             Receive response times: 10

    Min/Max/Average round trip time: 15/32/17

    Square-Sum of round trip time: 3235

    Last packet received time: 2011-05-29 13:56:17.6

  Extended results:

    Packet loss ratio: 0%

    Failures due to timeout: 0

    Failures due to internal error: 0

    Failures due to other errors: 0

    Packets out of sequence: 0

    Packets arrived late: 0

  ICMP-jitter results:

    RTT number: 10

    Min positive SD: 4                     Min positive DS: 1

    Max positive SD: 21                    Max positive DS: 28

    Positive SD number: 5                  Positive DS number: 4

    Positive SD sum: 52                    Positive DS sum: 38

    Positive SD average: 10                Positive DS average: 10

    Positive SD square-sum: 754            Positive DS square-sum: 460

    Min negative SD: 1                     Min negative DS: 6

    Max negative SD: 13                    Max negative DS: 22

    Negative SD number: 4                  Negative DS number: 5

    Negative SD sum: 38                    Negative DS sum: 52

    Negative SD average: 10                Negative DS average: 10

    Negative SD square-sum: 460            Negative DS square-sum: 754

  One way results:

    Max SD delay: 15                       Max DS delay: 16

    Min SD delay: 7                        Min DS delay: 7

    Number of SD delay: 10                 Number of DS delay: 10

    Sum of SD delay: 78                    Sum of DS delay: 85

    Square-Sum of SD delay: 666            Square-Sum of DS delay: 787

    Lost packets for unknown reason: 0

# Display the statistics of the ICMP jitter operation.

[AC] display nqa statistics admin test1

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

  NO. : 1

    Start time: 2015-07-10 13:56:14.0

    Life time: 47 seconds

    Send operation times: 410            Receive response times: 410

    Min/Max/Average round trip time: 1/93/19

    Square-Sum of round trip time: 206176

  Extended results:

    Packet loss ratio: 0%

    Failures due to timeout: 0

    Failures due to internal error: 0

    Failures due to other errors: 0

    Packets out of sequence: 0

    Packets arrived late: 0

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

    Lost packets for unknown reason: 0

FTP operation configuration example

Network requirements

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

Figure 9 Network diagram

 

Configuration procedure

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

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

# Create an FTP operation.

<AC> system-view

[AC] nqa entry admin test1

[AC-nqa-admin-test1] type ftp

# Specify the URL of the FTP server.

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

# Specify 10.1.1.1 as the source IP address.

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

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

[AC-nqa-admin-test1-ftp] operation put

[AC-nqa-admin-test1-ftp] filename config.txt

# Set the username to admin for the FTP operation.

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

# Set the password to systemtest for the FTP operation.

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

# Enable the saving of history records.

[AC-nqa-admin-test1-ftp] history-record enable

[AC-nqa-admin-test1-ftp] quit

# Start the FTP operation.

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

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

[AC] undo nqa schedule admin test1

# Display the most recent result of the FTP operation.

[AC] display nqa result admin test1

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

    Send operation times: 1              Receive response times: 1

    Min/Max/Average round trip time: 173/173/173

    Square-Sum of round trip time: 29929

    Last succeeded probe time: 2011-11-22 10:07:28.6

  Extended results:

    Packet loss ratio: 0%

    Failures due to timeout: 0

    Failures due to disconnect: 0

    Failures due to no connection: 0

    Failures due to internal error: 0

    Failures due to other errors: 0

# Display the history records of the FTP operation.

[AC] display nqa history admin test1

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

  Index      Response     Status           Time

  1          173          Succeeded        2011-11-22 10:07:28.6

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

HTTP operation configuration example

Network requirements

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

Figure 10 Network diagram

 

Configuration procedure

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

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

# Create an HTTP operation.

<AC> system-view

[AC] nqa entry admin test1

[AC-nqa-admin-test1] type http

# Specify the URL of the HTTP server.

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

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

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

# Configure the operation to use HTTP version 1.0.

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

# Enable the saving of history records.

[AC-nqa-admin-test1-http] history-record enable

[AC-nqa-admin-test1-http] quit

# Start the HTTP operation.

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

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

[AC] undo nqa schedule admin test1

# Display the most recent result of the HTTP operation.

[AC] display nqa result admin test1

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

    Send operation times: 1              Receive response times: 1

    Min/Max/Average round trip time: 64/64/64

    Square-Sum of round trip time: 4096

    Last succeeded probe time: 2011-11-22 10:12:47.9

  Extended results:

    Packet loss ratio: 0%

    Failures due to timeout: 0

    Failures due to disconnect: 0

    Failures due to no connection: 0

    Failures due to internal error: 0

    Failures due to other errors: 0

# Display the history records of the HTTP operation.

[AC] display nqa history admin test1

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

  Index      Response     Status           Time

  1          64           Succeeded        2011-11-22 10:12:47.9

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

UDP jitter operation configuration example

Network requirements

As shown in Figure 11, configure a UDP jitter operation to test the jitter, delay, and round-trip time between the AC and the device.

Figure 11 Network diagram

 

Configuration procedure

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

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

3.     Configure NTP to ensure that the devices are time synchronized with each other. (Details not shown.)

4.     Configure the device:

# Enable the NQA server.

<Device> system-view

[Device] nqa server enable

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

[Device] nqa server udp-echo 10.2.2.2 9000

5.     Configure the AC:

# Create a UDP jitter operation.

<AC> system-view

[AC] nqa entry admin test1

[AC-nqa-admin-test1] type udp-jitter

# Specify 10.2.2.2 as the destination address of the operation.

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

# Set the destination port number to 9000.

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

# Configure the operation to repeat every 1000 milliseconds.

[AC-nqa-admin-test1-udp-jitter] frequency 1000

[AC-nqa-admin-test1-udp-jitter] quit

# Start the UDP jitter operation.

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

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

[AC] undo nqa schedule admin test1

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

[AC] display nqa result admin test1

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

    Send operation times: 10             Receive response times: 10

    Min/Max/Average round trip time: 15/32/17

    Square-Sum of round trip time: 3235

    Last packet received time: 2011-05-29 13:56:17.6

  Extended results:

    Packet loss ratio: 0%

    Failures due to timeout: 0

    Failures due to internal error: 0

    Failures due to other errors: 0

    Packets out of sequence: 0

    Packets arrived late: 0

  UDP-jitter results:

   RTT number: 10

    Min positive SD: 4                     Min positive DS: 1

    Max positive SD: 21                    Max positive DS: 28

    Positive SD number: 5                  Positive DS number: 4

    Positive SD sum: 52                    Positive DS sum: 38

    Positive SD average: 10                Positive DS average: 10

    Positive SD square-sum: 754            Positive DS square-sum: 460

    Min negative SD: 1                     Min negative DS: 6

    Max negative SD: 13                    Max negative DS: 22

    Negative SD number: 4                  Negative DS number: 5

    Negative SD sum: 38                    Negative DS sum: 52

    Negative SD average: 10                Negative DS average: 10

    Negative SD square-sum: 460            Negative DS square-sum: 754

  One way results:

    Max SD delay: 15                       Max DS delay: 16

    Min SD delay: 7                        Min DS delay: 7

    Number of SD delay: 10                 Number of DS delay: 10

    Sum of SD delay: 78                    Sum of DS delay: 85

    Square-Sum of SD delay: 666            Square-Sum of DS delay: 787

    SD lost packets: 0                   DS lost packets: 0

    Lost packets for unknown reason: 0

# Display the statistics of the UDP jitter operation.

[AC] display nqa statistics admin test1

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

  NO. : 1

    Start time: 2011-05-29 13:56:14.0

    Life time: 47 seconds

    Send operation times: 410            Receive response times: 410

    Min/Max/Average round trip time: 1/93/19

    Square-Sum of round trip time: 206176

  Extended results:

    Packet loss ratio: 0%

    Failures due to timeout: 0

    Failures due to internal error: 0

    Failures due to other errors: 0

    Packets out of sequence: 0

    Packets arrived late: 0

  UDP-jitter results:

   RTT number: 410

    Min positive SD: 3                     Min positive DS: 1

    Max positive SD: 30                    Max positive DS: 79

    Positive SD number: 186                Positive DS number: 158

    Positive SD sum: 2602                  Positive DS sum: 1928

    Positive SD average: 13                Positive DS average: 12

    Positive SD square-sum: 45304          Positive DS square-sum: 31682

    Min negative SD: 1                     Min negative DS: 1

    Max negative SD: 30                    Max negative DS: 78

    Negative SD number: 181                Negative DS number: 209

    Negative SD sum: 181                   Negative DS sum: 209

    Negative SD average: 13                Negative DS average: 14

    Negative SD square-sum: 46994          Negative DS square-sum: 3030

  One way results:

    Max SD delay: 46                       Max DS delay: 46

    Min SD delay: 7                        Min DS delay: 7

    Number of SD delay: 410                Number of DS delay: 410

    Sum of SD delay: 3705                  Sum of DS delay: 3891

    Square-Sum of SD delay: 45987          Square-Sum of DS delay: 49393

    SD lost packets: 0                   DS lost packets: 0

    Lost packets for unknown reason: 0

SNMP operation configuration example

Network requirements

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

Figure 12 Network diagram

 

Configuration procedure

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

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

3.     Configure the SNMP agent:

# Set the SNMP version to all.

<Device> system-view

[Device] snmp-agent sys-info version all

# Set the read community to public.

[Device] snmp-agent community read public

# Set the write community to private.

[Device] snmp-agent community write private

4.     Configure the AC:

# Create an SNMP operation.

<AC> system-view

[AC] nqa entry admin test1

[AC-nqa-admin-test1] type snmp

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

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

# Enable the saving of history records.

[AC-nqa-admin-test1-snmp] history-record enable

[AC-nqa-admin-test1-snmp] quit

# Start the SNMP operation.

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

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

[AC] undo nqa schedule admin test1

# Display the most recent result of the SNMP operation.

[AC] display nqa result admin test1

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

    Send operation times: 1              Receive response times: 1

    Min/Max/Average round trip time: 50/50/50

    Square-Sum of round trip time: 2500

    Last succeeded probe time: 2011-11-22 10:24:41.1

  Extended results:

    Packet loss ratio: 0%

    Failures due to timeout: 0

    Failures due to internal error: 0

    Failures due to other errors: 0

# Display the history records of the SNMP operation.

[AC] display nqa history admin test1

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

  Index      Response     Status           Time

  1          50           Succeeded        2011-11-22 10:24:41.1

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

TCP operation configuration example

Network requirements

As shown in Figure 13, configure a TCP operation to test the time required for the AC and the device to establish a TCP connection.

Figure 13 Network diagram

 

Configuration procedure

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

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

3.     Configure the device:

# Enable the NQA server.

<Device> system-view

[Device] nqa server enable

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

[Device] nqa server tcp-connect 10.2.2.2 9000

4.     Configure the AC:

# Create a TCP operation.

<AC> system-view

[AC] nqa entry admin test1

[AC-nqa-admin-test1] type tcp

# Specify 10.2.2.2 as the destination IP address.

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

# Set the destination port number to 9000.

[AC-nqa-admin-test1-tcp] destination port 9000

# Enable the saving of history records.

[AC-nqa-admin-test1-tcp] history-record enable

[AC-nqa-admin-test1-tcp] quit

# Start the TCP operation.

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

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

[AC] undo nqa schedule admin test1

# Display the most recent result of the TCP operation.

[AC] display nqa result admin test1

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

    Send operation times: 1              Receive response times: 1

    Min/Max/Average round trip time: 13/13/13

    Square-Sum of round trip time: 169

    Last succeeded probe time: 2011-11-22 10:27:25.1

  Extended results:

    Packet loss ratio: 0%

    Failures due to timeout: 0

    Failures due to disconnect: 0

    Failures due to no connection: 0

    Failures due to internal error: 0

    Failures due to other errors: 0

# Display the history records of the TCP operation.

[AC] display nqa history admin test1

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

  Index      Response     Status           Time

  1          13           Succeeded        2011-11-22 10:27:25.1

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

UDP echo operation configuration example

Network requirements

As shown in Figure 14, configure a UDP echo operation to test the round-trip time between the AC and the device. The destination port number is 8000.

Figure 14 Network diagram

 

Configuration procedure

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

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

3.     Configure the device:

# Enable the NQA server.

<Device> system-view

[Device] nqa server enable

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

[Device] nqa server udp-echo 10.2.2.2 8000

4.     Configure the AC:

# Create a UDP echo operation.

<AC> system-view

[AC] nqa entry admin test1

[AC-nqa-admin-test1] type udp-echo

# Specify 10.2.2.2 as the destination IP address.

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

# Set the destination port number to 8000.

[AC-nqa-admin-test1-udp-echo] destination port 8000

# Enable the saving of history records.

[AC-nqa-admin-test1-udp-echo] history-record enable

[AC-nqa-admin-test1-udp-echo] quit

# Start the UDP echo operation.

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

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

[AC] undo nqa schedule admin test1

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

[AC] display nqa result admin test1

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

    Send operation times: 1              Receive response times: 1

    Min/Max/Average round trip time: 25/25/25

    Square-Sum of round trip time: 625

    Last succeeded probe time: 2011-11-22 10:36:17.9

  Extended results:

    Packet loss ratio: 0%

    Failures due to timeout: 0

    Failures due to internal error: 0

    Failures due to other errors: 0

# Display the history records of the UDP echo operation.

[AC] display nqa history admin test1

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

  Index      Response     Status           Time

  1          25           Succeeded        2011-11-22 10:36:17.9

The output shows that the round-trip time between the AC and port 8000 on the device is 25 milliseconds.

NQA collaboration configuration example

Network requirements

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

Figure 15 Network diagram

 

Configuration procedure

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

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

<AC> system-view

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

3.     Configure an ICMP echo operation:

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

[AC] nqa entry admin test1

# Configure the NQA operation type as ICMP echo.

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

# Specify 10.2.1.1 as the destination IP address.

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

# Configure the operation to repeat every 100 milliseconds.

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

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

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

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

# Start the ICMP operation.

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

4.     Create track entry 1, and associate it with reaction entry 1 of the NQA operation.

[AC] track 1 nqa entry admin test1 reaction 1

Verifying the configuration

# Display information about all the track entries on the AC.

[AC] display track all

Track ID: 1

  State: Positive

  Duration: 0 days 0 hours 0 minutes 0 seconds

  Notification delay: Positive 0, Negative 0 (in seconds)

  Tracked object:

    NQA entry: admin test1

    Reaction: 1

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

[AC] display ip routing-table

 

Destinations : 13        Routes : 13

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

0.0.0.0/32          Direct 0    0            127.0.0.1       InLoop0

10.1.1.0/24         Static 60   0            10.2.1.1        Vlan3

10.2.1.0/24         Direct 0    0            10.2.1.2        Vlan3

10.2.1.0/32         Direct 0    0            10.2.1.2        Vlan3

10.2.1.2/32         Direct 0    0            127.0.0.1       InLoop0

10.2.1.255/32       Direct 0    0            10.2.1.2        Vlan3

127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0

127.0.0.0/32        Direct 0    0            127.0.0.1       InLoop0

127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0

127.255.255.255/32  Direct 0    0            127.0.0.1       InLoop0

224.0.0.0/4         Direct 0    0            0.0.0.0         NULL0

224.0.0.0/24        Direct 0    0            0.0.0.0         NULL0

255.255.255.255/32  Direct 0    0            127.0.0.1       InLoop0

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

# Remove the IP address of VLAN-interface 3 on Switch A.

<SwitchA> system-view

[SwitchA] interface vlan-interface 3

[SwitchA-Vlan-interface3] undo ip address

# Display information about all the track entries on the AC.

[AC] display track all

Track ID: 1

  State: Negative

  Duration: 0 days 0 hours 0 minutes 0 seconds

  Notification delay: Positive 0, Negative 0 (in seconds)

  Tracked object:

    NQA entry: admin test1

    Reaction: 1

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

[AC] display ip routing-table

 

Destinations : 12        Routes : 12

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

0.0.0.0/32          Direct 0    0            127.0.0.1       InLoop0

10.2.1.0/24         Direct 0    0            10.2.1.2        Vlan3

10.2.1.0/32         Direct 0    0            10.2.1.2        Vlan3

10.2.1.2/32         Direct 0    0            127.0.0.1       InLoop0

10.2.1.255/32       Direct 0    0            10.2.1.2        Vlan3

127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0

127.0.0.0/32        Direct 0    0            127.0.0.1       InLoop0

127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0

127.255.255.255/32  Direct 0    0            127.0.0.1       InLoop0

224.0.0.0/4         Direct 0    0            0.0.0.0         NULL0

224.0.0.0/24        Direct 0    0            0.0.0.0         NULL0

255.255.255.255/32  Direct 0    0            127.0.0.1       InLoop0

The output shows that the static route does not exist, and the status of the track entry is negative.

ICMP template configuration example

Network requirements

As shown in Figure 16, configure an ICMP template for a feature to perform the ICMP echo operation from the AC to Device A.

Figure 16 Network diagram

 

Configuration procedure

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

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

# Create ICMP template icmp.

<AC> system-view

[AC] nqa template icmp icmp

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

[AC-nqatplt-icmp-icmp] destination ip 10.2.2.2

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

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

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

[AC-nqatplt-icmp-icmp] frequency 3000

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

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

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

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

TCP template configuration example

Network requirements

As shown in Figure 17, configure a TCP template for a feature to perform the TCP operation. The operation tests whether the AC can establish a TCP connection to the device.

Figure 17 Network diagram

 

Configuration procedure

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

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

3.     Configure the device:

# Enable the NQA server.

<Device> system-view

[Device] nqa server enable

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

[Device] nqa server tcp-connect 10.2.2.2 9000

4.     Configure the AC:

# Create TCP template tcp.

<AC> system-view

[AC] nqa template tcp tcp

# Specify 10.2.2.2 as the destination IP address.

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

# Set the destination port number to 9000.

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

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

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

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

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

TCP half open template configuration example

Network requirements

As shown in Figure 18, configure a TCP half open template for a feature to test whether the AC can provide the TCP service for the device.

Figure 18 Network diagram

 

Configuration procedure

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

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

3.     Configure the AC:

# Create TCP half open template test.

<AC> system-view

[AC] nqa template tcphalfopen test

# Specify 10.2.2.2 as the destination IP address.

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

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

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

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

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

UDP template configuration example

Network requirements

As shown in Figure 19, configure a UDP template for a feature to perform the UDP operation. The operation tests whether the AC can receive a response from the device.

Figure 19 Network diagram

 

Configuration procedure

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

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

3.     Configure the device:

# Enable the NQA server.

<Device> system-view

[Device] nqa server enable

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

[Device] nqa server udp-echo 10.2.2.2 9000

4.     Configure the AC:

# Create UDP template udp.

<AC> system-view

[AC] nqa template udp udp

# Specify 10.2.2.2 as the destination IP address.

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

# Set the destination port number to 9000.

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

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

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

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

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

HTTP template configuration example

Network requirements

As shown in Figure 20, configure an HTTP template for a feature to perform the HTTP operation. The operation tests whether the NQA client can get data from the HTTP server.

Figure 20 Network diagram

 

Configuration procedure

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

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

# Create HTTP template http.

<AC> system-view

[AC] nqa template http http

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

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

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

[AC-nqatplt-http-http] operation get

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

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

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

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

HTTPS template configuration example

Network requirements

As shown in Figure 21, configure an HTTPS template for a feature to test whether the NQA client can get data from the HTTPS server.

Figure 21 Network diagram

 

Configuration procedure

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

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

# Configure an SSL client policy named abc on the AC, and make sure the AC can use the policy to connect to the HTTPS server on the device. (Details not shown.)

# Create HTTPS template test.

<AC> system-view

[AC] nqa template https https

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

[AC-nqatplt-https-https] url https://10.2.2.2/index.htm

# Specify the SSL client policy abc for the HTTPS template.

[AC-nqatplt-https-https] ssl-client-policy abc

# Set the HTTPS operation type to get (the default HTTPS operation type).

[AC-nqatplt-https-https] operation get

# Set the HTTPS version to 1.0 (the default HTTPS version).

[AC-nqatplt-https-https] version v1.0

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

[AC-nqatplt-https-https] reaction trigger probe-pass 2

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

[AC-nqatplt-https-https] reaction trigger probe-fail 2

FTP template configuration example

Network requirements

As shown in Figure 22, configure an FTP template for a feature to perform the FTP operation. The operation tests whether the AC can upload a file to the FTP server. The login username and password are admin and systemtest, respectively. The file to be transferred to the FTP server is config.txt.

Figure 22 Network diagram

 

Configuration procedure

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

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

# Create FTP template ftp.

<AC> system-view

[AC] nqa template ftp ftp

# Specify the URL of the FTP server.

[AC-nqatplt-ftp-ftp] url ftp://10.2.2.2

# Specify 10.1.1.1 as the source IP address.

[AC-nqatplt-ftp-ftp] source ip 10.1.1.1

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

[AC-nqatplt-ftp-ftp] operation put

[AC-nqatplt-ftp-ftp] filename config.txt

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

[AC-nqatplt-ftp-ftp] username admin

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

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

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

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

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

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

RADIUS template configuration example

Network requirements

As shown in Figure 23, configure a RADIUS template for a feature to test whether the device can provide authentication service for the AC. The username and password are admin and systemtest, respectively. The shared key is 123456 for secure RADIUS authentication.

Figure 23 Network diagram

 

Configuration procedure

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

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

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

# Create RADIUS template radius.

<AC> system-view

[AC] nqa template radius radius

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

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

# Set the username to admin.

[AC-nqatplt-radius-radius] username admin

# Set the password to systemtest.

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

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

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

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

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

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

[AC-nqatplt-radius-radius] reaction trigger probe-fail 2

SSL template configuration example

Network requirements

As shown in Figure 24, configure an SSL template for a feature to test whether the AC can establish an SSL connection to the SSL server.

Figure 24 Network diagram

 

Configuration procedure

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

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

# Configure an SSL client policy named abc on the AC, and make sure the AC can use the policy to connect to the SSL server on the device. (Details not shown.)

# Create SSL template ssl.

<AC> system-view

[AC] nqa template ssl ssl

# Set the destination IP address and port number to 10.2.2.2 and 9000, respectively.

[AC-nqatplt-ssl-ssl] destination ip 10.2.2.2

[AC-nqatplt-ssl-ssl] destination port 9000

# Specify the SSL client policy abc for the SSL template.

[AC-nqatplt-ssl-ssl] ssl-client-policy abc

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

[AC-nqatplt-ssl-ssl] reaction trigger probe-pass 2

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

[AC-nqatplt-ssl-ssl] reaction trigger probe-fail 2


Configuring NTP

Synchronize your device with a trusted time source by using the Network Time Protocol (NTP) or changing the system time before you run it on a live network. Various tasks, including network management, charging, auditing, and distributed computing depend on an accurate system time setting, because the timestamps of system messages and logs use the system time.

Overview

NTP is typically used in large networks to dynamically synchronize time among network devices. It guarantees higher clock accuracy than manual system clock setting. In a small network that does not require high clock accuracy, you can keep time synchronized among devices by changing their system clocks one by one.

NTP runs over UDP and uses UDP port 123.

 

 

NOTE:

NTP is supported by the following Layer 3 interfaces:

·     Layer 3 Ethernet interfaces.

·     Layer 3 Ethernet subinterfaces.

·     VLAN interfaces.

·     Tunnel interfaces.

 

How NTP works

Figure 25 shows how NTP synchronizes the system time between two devices (Device A and Device B, in this example). Assume that:

·     Prior to the time synchronization, the time is set to 10:00:00 am for Device A and 11:00:00 am for Device B.

·     Device B is used as the NTP server. Device A is to be synchronized to Device B.

·     It takes 1 second for an NTP message to travel from Device A to Device B, and from Device B to Device A.

·     It takes 1 second for Device B to process the NTP message.

Figure 25 Basic work flow

 

The synchronization process is as follows:

1.     Device A sends Device B an NTP message, which is timestamped when it leaves Device A. The time stamp is 10:00:00 am (T1).

2.     When this NTP message arrives at Device B, Device B adds a timestamp showing the time when the message arrived at Device B. The timestamp is 11:00:01 am (T2).

3.     When the NTP message leaves Device B, Device B adds a timestamp showing the time when the message left Device B. The timestamp is 11:00:02 am (T3).

4.     When Device A receives the NTP message, the local time of Device A is 10:00:03 am (T4).

Up to now, Device A can calculate the following parameters based on the timestamps:

·     The roundtrip delay of the NTP message: Delay = (T4 – T1) – (T3 – T2) = 2 seconds.

·     Time difference between Device A and Device B: Offset = [ (T2 – T1) + (T3 – T4) ] /2 = 1 hour.

Based on these parameters, Device A can be synchronized to Device B.

This is only a rough description of the work mechanism of NTP. For more information, see the related protocols and standards.

NTP architecture

NTP uses stratums 1 to 16 to define clock accuracy, as shown in Figure 26. A lower stratum value represents higher accuracy. Clocks at stratums 1 through 15 are in synchronized state, and clocks at stratum 16 are not synchronized.

Figure 26 NTP architecture

 

A stratum 1 NTP server gets its time from an authoritative time source, such as an atomic clock. It provides time for other devices as the primary NTP server. A stratum 2 time server receives its time from a stratum 1 time server, and so on.

To ensure time accuracy and availability, you can specify multiple NTP servers for a device. The device selects an optimal NTP server as the clock source based on parameters such as stratum. The clock that the device selects is called the reference source. For more information about clock selection, see the related protocols and standards.

If the devices in a network cannot synchronize to an authoritative time source, you can perform the following tasks:

·     Select a device that has a relatively accurate clock from the network.

·     Use the local clock of the device as the reference clock to synchronize other devices in the network.

Association modes

NTP supports the following association modes:

·     Client/server mode

·     Symmetric active/passive mode

·     Broadcast mode

·     Multicast mode

Table 2 NTP association modes

Mode

Working process

Principle

Application scenario

Client/server

On the client, specify the IP address of the NTP server.

A client sends a clock synchronization message to the NTP servers. Upon receiving the message, the servers automatically operate in server mode and send a reply.

If the client can be synchronized to multiple time servers, it selects an optimal clock and synchronizes its local clock to the optimal reference source after receiving the replies from the servers.

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

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

Symmetric active/passive

On the symmetric active peer, specify the IP address of the symmetric passive peer.

A symmetric active peer periodically sends clock synchronization messages to a symmetric passive peer. The symmetric passive peer automatically operates in symmetric passive mode and sends a reply.

If the symmetric active peer can be synchronized to multiple time servers, it selects an optimal clock and synchronizes its local clock to the optimal reference source after receiving the replies from the servers.

A symmetric active peer and a symmetric passive peer can be synchronized to each other. If both of them are synchronized, the peer with a higher stratum is synchronized to the peer with a lower stratum.

As Figure 26 shows, this mode is most often used between servers with the same stratum to operate as a backup for one another. If a server fails to communicate with all the servers of a lower stratum, the server can still synchronize to the servers of the same stratum.

Broadcast

A server periodically sends clock synchronization messages to the broadcast address 255.255.255.255. Clients listen to the broadcast messages from the servers to synchronize to the server according to the broadcast messages.

When a client receives the first broadcast message, the client and the server start to exchange messages to calculate the network delay between them. Then, only the broadcast server sends clock synchronization messages.

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

A broadcast server sends clock synchronization messages to synchronize clients in the same subnet. As Figure 26 shows, broadcast mode is intended for configurations involving one or a few servers and a potentially large client population.

The broadcast mode has a lower time accuracy than the client/server and symmetric active/passive modes because only the broadcast servers send clock synchronization messages.

Multicast

A multicast server periodically sends clock synchronization messages to the user-configured multicast address. Clients listen to the multicast messages from servers and synchronize to the server according to the received messages.

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

A multicast server can provide time synchronization for clients in the same subnet or in different subnets.

The multicast mode has a lower time accuracy than the client/server and symmetric active/passive modes.

 

In this document, an "NTP server" or a "server" refers to a device that operates as an NTP server in client/server mode. Time servers refer to all the devices that can provide time synchronization, including NTP servers, NTP symmetric peers, broadcast servers, and multicast servers.

NTP security

To improve time synchronization security, NTP provides the access control and authentication functions.

NTP access control

You can control NTP access by using an ACL. The access rights are in the following order, from least restrictive to most restrictive:

·     PeerAllows time requests and NTP control queries (such as alarms, authentication status, and time server information) and allows the local device to synchronize itself to a peer device.

·     ServerAllows time requests and NTP control queries, but does not allow the local device to synchronize itself to a peer device.

·     SynchronizationAllows only time requests from a system whose address passes the access list criteria.

·     QueryAllows only NTP control queries from a peer device to the local device.

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

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

·     If the IP address of the peer device matches a permit statement in an ACL, the access right is granted to the peer device. If a deny statement or no ACL is matched, no access right is granted.

·     If no ACL is specified for an access right or the ACL specified for the access right is not created, the access right is not granted.

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

·     If none of the IPv4 ACLs specified for the access rights contains rules, no access right is granted.

This feature provides minimal security for a system running NTP. A more secure method is NTP authentication.

NTP authentication

Use this feature to authenticate the NTP messages for security purposes. If an NTP message passes authentication, the device can receive it and get time synchronization information. If not, the device discards the message. This function makes sure the device does not synchronize to an unauthorized time server.

Figure 27 NTP authentication

 

As shown in Figure 27, NTP authentication is performed as follows:

1.     The sender uses the key identified by the key ID to calculate a digest for the NTP message through the MD5 algorithm. Then it sends the calculated digest together with the NTP message and key ID to the receiver.

2.     Upon receiving the message, the receiver performs the following actions:

a.     Finds the key according to the key ID in the message.

b.     Uses the key and the MD5 algorithm to calculate the digest for the message.

c.     Compares the digest with the digest contained in the NTP message.

-     If they are different, the receiver discards the message.

-     If they are the same, the local device determines whether the sender is allowed to use the authentication ID. If the sender is allowed to use the authentication ID, the receiver accepts the message. If the sender is not allowed to use the authentication ID, the receiver discards the message.

Protocols and standards

·     RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis

·     RFC 5905, Network Time Protocol Version 4: Protocol and Algorithms Specification

Configuration restrictions and guidelines

When you configure NTP, follow these restrictions and guidelines:

·     You cannot configure both NTP and SNTP on the same device.

·     Do not configure NTP on an aggregate member port.

·     The NTP service and SNTP service are mutually exclusive. You can only enable either NTP service or SNTP service at a time.

·     To ensure time synchronization accuracy, do not specify more than one reference source. Doing so might cause frequent time changes or even synchronization failures.

Configuration task list

Tasks at a glance

(Required.) Enabling the NTP service

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

·     Configuring NTP association modes

·     Configuring the local clock as a reference source

(Optional.) Configuring access control rights

(Optional.) Configuring NTP authentication

(Optional.) Configuring NTP optional parameters

 

Enabling the NTP service

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable the NTP service.

ntp-service enable

By default, the NTP service is not enabled.

 

Configuring NTP association modes

This section describes how to configure NTP association modes.

Configuring NTP in client/server mode

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

Follow these guidelines when you configure an NTP client:

·     A server must be synchronized by other devices or use its local clock as a reference source before synchronizing an NTP client. Otherwise, the client will not be synchronized to the NTP server.

·     If the stratum level of a server is higher than or equal to a client, the client will not synchronize to that server.

·     You can configure multiple servers by repeating the ntp-service unicast-server and ntp-service ipv6 unicast-server commands.

To configure an NTP client:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Specify an NTP server for the device.

·     Specify an NTP server for the device:
ntp-service unicast-server { server-name | ip-address } [ authentication-keyid keyid | priority | source interface-type interface-number | version number ] *

·     Specify an IPv6 NTP server for the device:
ntp-service ipv6 unicast-server { server-name | ipv6-address } [ authentication-keyid keyid | priority | source interface-type interface-number ] *

By default, no NTP server is specified for the device.

 

Configuring NTP in symmetric active/passive mode

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

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

·     Execute the ntp-service enable command on a symmetric passive peer to enable NTP. Otherwise, the symmetric-passive peer will not process NTP messages from a symmetric-active peer.

·     Either the symmetric-active peer, or the symmetric-passive peer, or both of them must be in synchronized state. Otherwise, their time cannot be synchronized.

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

To configure a symmetric-active peer:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

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

·     Specify a symmetric-passive peer:
ntp-service
unicast-peer { peer-name | ip-address } [ authentication-keyid keyid | priority | source interface-type interface-number | version number ] *

·     Specify an IPv6 symmetric-passive peer:
ntp-service ipv6 unicast-peer
{ peer-name | ipv6-address } [ authentication-keyid keyid | priority | source interface-type interface-number ] *

By default, no symmetric-passive peer is specified.

 

Configuring NTP in broadcast mode

A broadcast server must be synchronized by other devices or use its local clock as a reference source before synchronizing a broadcast client. Otherwise, the broadcast client will not be synchronized to the broadcast server.

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

Configuring a broadcast client

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

Enter the interface for receiving NTP broadcast messages.

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

ntp-service broadcast-client

By default, the device does not operate in broadcast client mode.

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

 

Configuring the broadcast server

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

Enter the interface for sending NTP broadcast messages.

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

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

By default, the device does not operate in broadcast server mode.

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

 

Configuring NTP in multicast mode

A multicast server must be synchronized by other devices or use its local clock as a reference source before synchronizing a multicast client. Otherwise, the multicast client will not be synchronized to the multicast server.

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

Configuring a multicast client

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

Enter the interface for receiving NTP multicast messages.

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

·     Configure the device to operate in multicast client mode:
ntp-service
multicast-client [ ip-address ]

·     Configure the device to operate in IPv6 multicast client mode:
ntp-service ipv6 multicast-client
ipv6-multicast-address

By default, the device does not operate in multicast server mode.

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

 

Configuring the multicast server

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

Enter the interface for sending NTP multicast message.

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

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

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

By default, the device does not operate in multicast server mode.

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

 

Configuring access control rights

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure the right for peer devices to access the NTP services on the local device.

·     Configure the right for peer devices to access the IPv4 NTP services on the local device:
ntp-service access { peer | query | server | synchronization } acl ipv4-acl-number

·     Configure the right for peer devices to access the IPv6 NTP services on the local device:
ntp-service ipv6 { peer | query | server | synchronization } acl ipv
6-acl-number

By default, the right for peer devices to access the NTP services on the local device is peer.

 

Before you configure the NTP service access control right to the local device, create and configure an ACL associated with the access control right. For more information about ACL, see ACL and QoS Configuration Guide.

Configuring NTP authentication

This section provides instructions for configuring NTP authentication.

Configuring NTP authentication in client/server mode

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

To configure NTP authentication for a client:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable NTP authentication.

ntp-service authentication enable

By default, NTP authentication is disabled.

3.     Configure an NTP authentication key.

ntp-service authentication-keyid keyid authentication-mode md5 { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no NTP authentication key is configured.

4.     Configure the key as a trusted key.

ntp-service reliable authentication-keyid keyid

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

5.     Associate the specified key with an NTP server.

·     Associate the specified key with an NTP server:
ntp-service
unicast-server { server-name | ip-address } authentication-keyid keyid

·     Associate the specified key with an IPv6 NTP server:
ntp-service
ipv6 unicast-server { server-name | ipv6-address } authentication-keyid keyid

By default, a trusted key is not associated with an NTP server.

 

To configure NTP authentication for a server:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable NTP authentication.

ntp-service authentication enable

By default, NTP authentication is disabled.

3.     Configure an NTP authentication key.

ntp-service authentication-keyid keyid authentication-mode md5 { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no NTP authentication key is configured.

4.     Configure the key as a trusted key.

ntp-service reliable authentication-keyid keyid

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

 

NTP authentication results differ when different configurations are performed on client and server. For more information, see Table 3. (N/A in the table means that whether the configuration is performed does not make any difference.)

Table 3 NTP authentication results

Client

Server

Enable NTP authentication

Specify the server and key

Trusted key

Enable NTP authentication

Trusted key

Successful authentication

Yes

Yes

Yes

Yes

Yes

Failed authentication

Yes

Yes

Yes

Yes

No

Yes

Yes

Yes

No

N/A

Yes

Yes

No

N/A

N/A

Authentication not performed

Yes

No

N/A

N/A

N/A

No

N/A

N/A

N/A

N/A

 

Configuring NTP authentication in symmetric active/passive mode

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

To configure NTP authentication for an active peer:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable NTP authentication.

ntp-service authentication enable

By default, NTP authentication is disabled.

3.     Configure an NTP authentication key.

ntp-service authentication-keyid keyid authentication-mode md5 { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no NTP authentication key is configured.

4.     Configure the key as a trusted key.

ntp-service reliable authentication-keyid keyid

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

5.     Associate the specified key with a passive peer.

·     Associate the specified key with a passive peer:
ntp-service unicast-peer
{ ip-address | peer-name } authentication-keyid keyid

·     Associate the specified key with a passive peer:
ntp-service ipv6 unicast-peer
{ ipv6-address | peer-nameauthentication-keyid keyid

By default, a trusted key is not associated with a passive peer..

 

To configure NTP authentication for a passive peer:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable NTP authentication.

ntp-service authentication enable

By default, NTP authentication is disabled.

3.     Configure an NTP authentication key.

ntp-service authentication-keyid keyid authentication-mode md5 { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no NTP authentication key is configured.

4.     Configure the key as a trusted key.

ntp-service reliable authentication-keyid keyid

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

 

NTP authentication results differ when different configurations are performed on active peer and passive peer. For more information, see Table 4. (N/A in the table means that whether the configuration is performed does not make any difference.)

Table 4 NTP authentication results

Active peer

Passive peer

Enable NTP authentication

Specify the peer and key

Trusted key

Stratum level

Enable NTP authentication

Trusted key

Successful authentication

Yes

Yes

Yes

N/A

Yes

Yes

Failed authentication

Yes

Yes

Yes

N/A

Yes

No

Yes

Yes

Yes

N/A

No

N/A

Yes

No

N/A

N/A

Yes

N/A

No

N/A

N/A

N/A

Yes

N/A

Yes

Yes

No

Larger than the passive peer

N/A

N/A

Yes

Yes

No

Smaller than the passive peer

Yes

N/A

Authentication not performed

Yes

No

N/A

N/A

No

N/A

No

N/A

N/A

N/A

No

N/A

Yes

Yes

No

Smaller than the passive peer

No

N/A

 

Configuring NTP authentication in broadcast mode

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

To configure NTP authentication for a broadcast client:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable NTP authentication.

ntp-service authentication enable

By default, NTP authentication is disabled.

3.     Configure an NTP authentication key.

ntp-service authentication-keyid keyid authentication-mode md5 { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no NTP authentication key is configured.

4.     Configure the key as a trusted key.

ntp-service reliable authentication-keyid keyid

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

 

To configure NTP authentication for a broadcast server:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable NTP authentication.

ntp-service authentication enable

By default, NTP authentication is disabled.

3.     Configure an NTP authentication key.

ntp-service authentication-keyid keyid authentication-mode md5 { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no NTP authentication key is configured.

4.     Configure the key as a trusted key.

ntp-service reliable authentication-keyid keyid

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

5.     Enter interface view.

interface interface-type interface-number

N/A

6.     Associate the specified key with the broadcast server.

ntp-service broadcast-server authentication-keyid keyid

By default, the broadcast server is not associated with any key.

 

NTP authentication results differ when different configurations are performed on broadcast client and server. For more information, see Table 5. (N/A in the table means that whether the configuration is performed does not make any difference.)

Table 5 NTP authentication results

Broadcast server

Broadcast client

Enable NTP authentication

Specify the server and key

Trusted key

Enable NTP authentication

Trusted key

Successful authentication

Yes

Yes

Yes

Yes

Yes

Failed authentication

Yes

Yes

Yes

Yes

No

Yes

Yes

Yes

No

N/A

Yes

Yes

No

Yes

N/A

Yes

No

N/A

Yes

N/A

No

N/A

N/A

Yes

N/A

Authentication not performed

Yes

Yes

No

No

N/A

Yes

No

N/A

No

N/A

No

N/A

N/A

No

N/A

 

Configuring NTP authentication in multicast mode

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

To configure NTP authentication for a multicast client:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable NTP authentication.

ntp-service authentication enable

By default, NTP authentication is disabled.

3.     Configure an NTP authentication key.

ntp-service authentication-keyid keyid authentication-mode md5 { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no NTP authentication key is configured.

4.     Configure the key as a trusted key.

ntp-service reliable authentication-keyid keyid

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

 

To configure NTP authentication for a multicast server:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable NTP authentication.

ntp-service authentication enable

By default, NTP authentication is disabled.

3.     Configure an NTP authentication key.

ntp-service authentication-keyid keyid authentication-mode md5 { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no NTP authentication key is configured.

4.     Configure the key as a trusted key.

ntp-service reliable authentication-keyid keyid

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

5.     Enter interface view.

interface interface-type interface-number

N/A

6.     Associate the specified key with the multicast server.

·     Associate the specified key with a multicast server:
ntp-service multicast-server
[ ip-address ] authentication-keyid keyid

·     Associate the specified key with an IPv6 multicast server:
ntp-service ipv6 multicast-server
ipv6-multicast-address authentication-keyid keyid

By default, no multicast server is associated with the specified key.

 

NTP authentication results differ when different configurations are performed on broadcast client and server. For more information, see Table 6. (N/A in the table means that whether the configuration is performed does not make any difference.)

Table 6 NTP authentication results

Multicast server

Multicast client

Enable NTP authentication

Specify the server and key

Trusted key

Enable NTP authentication

Trusted key

Successful authentication

Yes

Yes

Yes

Yes

Yes

Failed authentication

Yes

Yes

Yes

Yes

No

Yes

Yes

Yes

No

N/A

Yes

Yes

No

Yes

N/A

Yes

No

N/A

Yes

N/A

No

N/A

N/A

Yes

N/A

Authentication not performed

Yes

Yes

No

No

N/A

Yes

No

N/A

No

N/A

No

N/A

N/A

No

N/A

 

Configuring NTP optional parameters

The configuration tasks in this section are optional tasks. Configure them to improve NTP security, performance, or reliability.

Specifying the source interface for NTP messages

To prevent interface status changes from causing NTP communication failures, configure the device to use the IP address of an interface that is always up. For example, you can configure the device to use a loopback interface as the source IP address for the NTP messages to be sent.

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

Follow these guidelines when you specify the source interface for NTP messages:

·     If you have specified the source interface for NTP messages in the ntp-service [ ipv6 ] unicast-server or ntp-service [ ipv6 ] unicast-peer command, the interface specified in the ntp-service [ ipv6 ] unicast-server or ntp-service [ ipv6 ] unicast-peer command works as the source interface for NTP messages.

·     If you have configured the ntp-service broadcast-server or ntp-service [ ipv6 ] multicast-server command, the source interface for the broadcast or multicast NTP messages is the interface configured with the respective command.

To specify the source interface for NTP messages:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Specify the source interface for NTP messages.

·     Specify the source interface for NTP messages:
ntp-service source
interface-type interface-number

·     Specify the source interface for IPv6 NTP messages:
ntp-service ipv6 source
interface-type interface-number

By default, no source interface is specified for NTP messages.

 

Disabling an interface from processing NTP messages

When NTP is enabled, all interfaces by default can process NTP messages. For security purposes, you can disable some of the interfaces from processing NTP messages.

To disable an interface from processing NTP messages:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Disable the interface from processing NTP messages.

·     For IPv4:
undo ntp-service inbound enable

·     For IPv6:
undo ntp-service ipv6 inbound enable

By default, an interface processes NTP messages.

 

Configuring the maximum number of dynamic associations

NTP has the following types of associations:

·     Static association—A manually created association.

·     Dynamic association—Temporary association created by the system during NTP operation. A dynamic association is removed if no messages are exchanged within about 12 minutes.

The following describes how an association is established in different association modes:

·     Client/server mode—After you specify an NTP server, the system creates a static association on the client. The server simply responds passively upon the receipt of a message, rather than creating an association (static or dynamic).

·     Symmetric active/passive mode—After you specify a symmetric-passive peer on a symmetric active peer, static associations are created on the symmetric-active peer, and dynamic associations are created on the symmetric-passive peer.

·     Broadcast or multicast mode—Static associations are created on the server, and dynamic associations are created on the client.

A single device can have a maximum of 128 concurrent associations, including static associations and dynamic associations.

Perform this task to restrict the number of dynamic associations to prevent dynamic associations from occupying too many system resources.

To configure the maximum number of dynamic associations:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure the maximum number of dynamic sessions allowed to be established.

ntp-service max-dynamic-sessions number

By default, the command can establish up to 100 dynamic sessions.

 

Setting a DSCP value for NTP packets

The DSCP value determines the sending precedence of a packet.

To set a DSCP value for NTP packets:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Set a DSCP value for NTP packets.

·     IPv4 packets:
ntp-service dscp dscp-value

·     IPv6 packets:
ntp-service ipv6 dscp dscp-value

The default DSCP value:

·     IPv4 packets48.

·     IPv6 packets56.

 

Configuring the local clock as a reference source

Follow these guidelines when you configure the local clock as a reference source:

·     Make sure the local clock can provide the time accuracy required for the network. After you configure the local clock as a reference source, the local clock is synchronized, and can operate as a time server to synchronize other devices in the network. If the local clock is incorrect, timing errors occur.

·     Before you configure this feature, adjust the local system time to make sure it is accurate.

·     Devices differ in clock precision. To avoid network flapping and clock synchronization failure, do not configure multiple reference sources on the same network segment.

To configure the local clock as a reference source:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure the local clock as a reference source.

ntp-service refclock-master [ ip-address ] [ stratum ]

By default, the device does not use the local clock as a reference source.

 

Displaying and maintaining NTP

Execute display commands in any view.

 

Task

Command

Display information about IPv6 NTP associations.

display ntp-service ipv6 sessions [ verbose ]

Display information about IPv4 NTP associations.

display ntp-service sessions [ verbose ]

Display information about NTP service status.

display ntp-service status

Display brief information about the NTP servers from the local device back to the primary reference source.

display ntp-service trace [ source interface-type interface-number ]

 

NTP configuration examples

NTP client/server mode configuration example

Network requirements

As shown in Figure 28:

·     Configure the local clock of the AC as a reference source, with the stratum level 2.

·     Configure the switch to operate in client mode and specify the AC as the NTP server for the switch.

Figure 28 Network diagram

 

Configuration procedure

1.     Assign an IP address to each interface, and make sure the AC and the switch can reach each other, as shown in Figure 28. (Details not shown.)

2.     Configure the AC:

# Enable the NTP service.

<AC> system-view

[AC] ntp-service enable

# Specify the local clock as the reference source, with the stratum level 2.

[AC] ntp-service refclock-master 2

3.     Configure the switch:

# Enable the NTP service.

<Switch> system-view

[Switch] ntp-service enable

# Specify the AC as the NTP server of the switch so that the switch is synchronized to the AC.

[Switch] ntp-service unicast-server 1.0.1.11

4.     Verify the configuration:

# Verify that the switch has synchronized to the AC, and the clock stratum level is 3 on the switch.

[Switch] display ntp-service status

 Clock status: synchronized

 Clock stratum: 3

 System peer: 1.0.1.11

 Local mode: client

 Reference clock ID: 1.0.1.11

 Leap indicator: 00

 Clock jitter: 0.000977 s

 Stability: 0.000 pps

 Clock precision: 2^-10

 Root delay: 0.00383 ms

 Root dispersion: 16.26572 ms

 Reference time: d0c6033f.b9923965  Wed, Dec 29 2010 18:58:07.724

# Verify that an IPv4 NTP association has been established between the switch and the AC.

[Switch] display ntp-service sessions

       source          reference       stra reach poll  now offset  delay disper

********************************************************************************

[12345]1.0.1.11        127.127.1.0        2     1   64   15   -4.0 0.0038 16.262

Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured.

 Total sessions: 1

IPv6 NTP client/server mode configuration example

Network requirements

As shown in Figure 29:

·     Configure the local clock of the AC as a reference source, with the stratum level 2.

·     Configure the switch to operate in client mode and specify the AC as the IPv6 NTP server for the switch.

Figure 29 Network diagram

 

Configuration procedure

1.     Assign an IP address to each interface, and make sure the AC and the switch can reach each other, as shown in Figure 29. (Details not shown.)

2.     Configure the AC:

# Enable the NTP service.

<AC> system-view

[AC] ntp-service enable

# Specify the local clock as the reference source, with the stratum level 2.

[AC] ntp-service refclock-master 2

3.     Configure the switch:

# Enable the NTP service.

<Switch> system-view

[Switch] ntp-service enable

# Specify the AC as the IPv6 NTP server of the switch so that the switch is synchronized to the AC.

[Switch] ntp-service ipv6 unicast-server 3000::34

4.     Verify the configuration:

# Verify that the switch has synchronized to the AC, and the clock stratum level is 3 on the switch.

[Switch] display ntp-service status

 Clock status: synchronized

 Clock stratum: 3

 System peer: 3000::34

 Local mode: client

 Reference clock ID: 163.29.247.19

 Leap indicator: 00

 Clock jitter: 0.000977 s

 Stability: 0.000 pps

 Clock precision: 2^-10

 Root delay: 0.02649 ms

 Root dispersion: 12.24641 ms

 Reference time: d0c60419.9952fb3e  Wed, Dec 29 2010 19:01:45.598

# Verify that an IPv6 NTP association has been established between the switch and the AC.

[Switch] display ntp-service ipv6 sessions

Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured.

 

 Source: [12345]3000::34

 Reference: 127.127.1.0          Clock stratum: 2

 Reachabilities: 15              Poll interval: 64

 Last receive time: 19           Offset: 0.0

 Roundtrip delay: 0.0            Dispersion: 0.0

 

 Total sessions: 1

NTP symmetric active/passive mode configuration example

Network requirements

As shown in Figure 30:

·     Configure the local clock of the AC as a reference source, with the stratum level 2.

·     Configure the AC to operate in symmetric-active mode and specify the switch as the passive peer of the AC.

Figure 30 Network diagram

 

Configuration procedure

1.     Assign an IP address to each interface, and make sure the AC and the switch can reach each other, as shown in Figure 30. (Details not shown.)

2.     Configure the switch:

# Enable the NTP service.

<Switch> system-view

[Switch] ntp-service enable

3.     Configure the AC:

# Enable the NTP service.

<AC> system-view

[AC] ntp-service enable

# Specify the local clock as the reference source, with the stratum level 2.

[AC] ntp-service refclock-master 2

# Configure the switch as a symmetric passive peer.

[AC] ntp-service unicast-peer 3.0.1.32

4.     Verify the configuration:

# Verify that the switch has synchronized to the AC and the clock stratum level is 3 on the switch.

[Switch] display ntp-service status

 Clock status: synchronized

 Clock stratum: 3

 System peer: 3.0.1.31

 Local mode: sym_passive

 Reference clock ID: 3.0.1.31

 Leap indicator: 00

 Clock jitter: 0.000916 s

 Stability: 0.000 pps

 Clock precision: 2^-17

 Root delay: 0.00609 ms

 Root dispersion: 1.95859 ms

 Reference time: 83aec681.deb6d3e5  Wed, Jan  8 2014 14:33:11.081

# Verify that an IPv4 NTP association has been established between the switch and the AC.

[Switch] display ntp-service sessions

       source          reference       stra reach poll  now offset  delay disper

********************************************************************************

   [12]3.0.1.31        127.127.1.0        2    62   64   34 0.4251 6.0882 1392.1

Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured.

 Total sessions: 1

IPv6 NTP symmetric active/passive mode configuration example

Network requirements

As shown in Figure 31:

·     Configure the local clock of the AC as a reference source, with the stratum level 2.

·     Configure the AC to operate in symmetric-active mode and specify the switch as the IPv6 passive peer of the AC.

Figure 31 Network diagram

 

Configuration procedure

1.     Assign an IP address to each interface, and make sure the AC and the switch can reach each other, as shown in Figure 31. (Details not shown.)

2.     Configure the switch:

# Enable the NTP service.

<Switch> system-view

[Switch] ntp-service enable

3.     Configure the AC:

# Enable the NTP service.

<AC> system-view

[AC] ntp-service enable

# Specify the local clock as the reference source, with the stratum level 2.

[AC] ntp-service refclock-master 2

# Configure the switch as an IPv6 symmetric passive peer.

[AC] ntp-service ipv6 unicast-peer 3000::36

4.     Verify the configuration:

# Verify that the switch has synchronized to the AC and the clock stratum level is 3 on the switch.

[Switch] display ntp-service status

 Clock status: synchronized

 Clock stratum: 3

 System peer: 3000::35

 Local mode: sym_passive

 Reference clock ID: 251.73.79.32

 Leap indicator: 11

 Clock jitter: 0.000977 s

 Stability: 0.000 pps

 Clock precision: 2^-10

 Root delay: 0.01855 ms

 Root dispersion: 9.23483 ms

 Reference time: d0c6047c.97199f9f  Wed, Dec 29 2010 19:03:24.590

# Verify that an IPv6 NTP association has been established between the switch and the AC.

[Switch] display ntp-service ipv6 sessions

Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured.

 

 Source:  [1234]3000::35

 Reference: 127.127.1.0          Clock stratum: 2

 Reachabilities: 15              Poll interval: 64

 Last receive time: 19           Offset: 0.0

 Roundtrip delay: 0.0            Dispersion: 0.0

 

 Total sessions: 1

Configuration example for NTP authentication in client/server mode

Network requirements

As shown in Figure 32:

·     Configure the local clock of the AC as a reference source, with the stratum level 2.

·     Configure the switch to operate in client mode and specify the AC as the NTP server of the switch.

·     Configure NTP authentication on both the AC and the switch.

Figure 32 Network diagram

 

Configuration procedure

1.     Assign an IP address to each interface, and make sure the AC and the switch can reach each other, as shown in Figure 32. (Details not shown.)

2.     Configure the AC:

# Enable the NTP service.

<AC> system-view

[AC] ntp-service enable

# Specify the local clock as the reference source, with the stratum level 2.

[AC] ntp-service refclock-master 2

3.     Configure the switch:

# Enable the NTP service.

<Switch> system-view

[Switch] ntp-service enable

# Enable NTP authentication on the switch.

[Switch] ntp-service authentication enable

# Set an authentication key, and input the key in plain text.

[Switch] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey

# Specify the key as a trusted key.

[Switch] ntp-service reliable authentication-keyid 42

# Specify the AC as the NTP server of the switch, and associate the server with key 42.

[Switch] ntp-service unicast-server 1.0.1.11 authentication-keyid 42

Before the switch can synchronize its clock to that of the AC, enable NTP authentication for the AC.

4.     Configure NTP authentication on the AC:

# Enable NTP authentication.

[AC] ntp-service authentication enable

# Set an authentication key, and input the key in plain text.

[AC] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey

# Specify the key as a trusted key.

[AC] ntp-service reliable authentication-keyid 42

5.     Verify the configuration:

# Verify that the switch has synchronized to the AC, and the clock stratum level is 3 on the switch.

[Switch] display ntp-service status

 Clock status: synchronized

 Clock stratum: 3

 System peer: 1.0.1.11

 Local mode: client

 Reference clock ID: 1.0.1.11

 Leap indicator: 00

 Clock jitter: 0.005096 s

 Stability: 0.000 pps

 Clock precision: 2^-10

 Root delay: 0.00655 ms

 Root dispersion: 1.15869 ms

 Reference time: d0c62687.ab1bba7d  Wed, Dec 29 2010 21:28:39.668

# Verify that an IPv4 NTP association has been established between the switch and the AC.

[Switch] display ntp-service sessions

       source          reference       stra reach poll  now offset  delay disper

********************************************************************************

 [1245]1.0.1.11        127.127.1.0        2     1   64  519   -0.0 0.0065    0.0

Notes: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured.

 Total sessions: 1


Configuring SNTP

SNTP is a simplified, client-only version of NTP specified in RFC 4330. SNTP supports only the client/server mode. An SNTP-enabled device can receive time from NTP servers, but cannot provide time services to other devices.

SNTP uses the same packet format and packet exchange procedure as NTP, but provides faster synchronization at the price of time accuracy.

If you specify multiple NTP servers for an SNTP client, the server with the best stratum is selected. If multiple servers are at the same stratum, the NTP server whose time packet is first received is selected.

Configuration restrictions and guidelines

You cannot configure both NTP and SNTP on the same device.

Configuration task list

Tasks at a glance

(Required.) Enabling the SNTP service

(Required.) Specifying an NTP server for the device

(Optional.) Configuring SNTP authentication

 

Enabling the SNTP service

The NTP service and SNTP service are mutually exclusive. You can only enable either NTP service or SNTP service at a time.

To enable the SNTP service:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable the SNTP service.

sntp enable

By default, the SNTP service is not enabled.

 

Specifying an NTP server for the device

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Specify an NTP server for the device.

·     For IPv4:
sntp unicast-server
{ server-name | ip-address } [ authentication-keyid keyid | source interface-type interface-number | version number ] *

·     For IPv6:
sntp ipv6 unicast-server
{ server-name | ipv6-address } [ authentication-keyid keyid | source interface-type interface-number ] *

By default, no NTP server is specified for the device.

Repeat this step to specify multiple NTP servers.

To use authentication, you must specify the authentication-keyid keyid option.

 

To use an NTP server as the time source, make sure its clock has been synchronized. If the stratum level of the NTP server is greater than or equal to that of the client, the client does not synchronize with the NTP server.

Configuring SNTP authentication

SNTP authentication makes sure an SNTP client is synchronized only to an authenticated trustworthy NTP server.

Follow these guidelines when you configure SNTP authentication:

·     Enable authentication on both the NTP server and the SNTP client.

·     Use the same authentication key ID and key on the NTP server and SNTP client. Specify the key as a trusted key on both the NTP server and the SNTP client. For information about configuring NTP authentication on an NTP server, see "Configuring NTP."

·     On the SNTP client, associate the specified key with the NTP server. Make sure the server is allowed to use the key ID for authentication on the client.

With authentication disabled, the SNTP client can synchronize with the NTP server regardless of whether the NTP server is enabled with authentication.

To configure SNTP authentication on the SNTP client:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable SNTP authentication.

sntp authentication enable

By default, SNTP authentication is disabled.

3.     Configure an SNTP authentication key.

sntp authentication-keyid keyid authentication-mode md5 { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no SNTP authentication key is configured.

4.     Specify the key as a trusted key.

sntp reliable authentication-keyid keyid

By default, no trusted key is specified.

5.     Associate the SNTP authentication key with an NTP server.

·     For IPv4:
sntp unicast-server
{ server-name | ip-address } authentication-keyid keyid

·     For IPv6:
sntp ipv6 unicast-server
{ server-name | ipv6-address } authentication-keyid keyid

By default, no NTP server is specified.

 

Displaying and maintaining SNTP

Execute display commands in any view.

 

Task

Command

Display information about all IPv6 SNTP associations.

display sntp ipv6 sessions

Display information about all IPv4 SNTP associations.

display sntp sessions

 

SNTP configuration example

Network requirements

As shown in Figure 33:

·     Configure the local clock of the AC as a reference source, with the stratum level 2.

·     Configure the switch to operate in SNTP client mode, and specify the AC as the NTP server.

·     Configure NTP authentication on the AC and SNTP authentication on the switch.

Figure 33 Network diagram

 

Configuration procedure

1.     Assign an IP address to each interface, and make sure the AC and the switch can reach each other, as shown in Figure 33. (Details not shown.)

2.     Configure the AC:

# Enable the NTP service.

<AC> system-view

[AC] ntp-service enable

# Configure the local clock of the AC as a reference source, with the stratum level 2.

[AC] ntp-service refclock-master 2

# Enable NTP authentication on the AC.

[AC] ntp-service authentication enable

# Configure an NTP authentication key, with the key ID of 10 and key value of aNiceKey. Input the key in plain text.

[AC] ntp-service authentication-keyid 10 authentication-mode md5 simple aNiceKey

# Specify the key as a trusted key.

[AC] ntp-service reliable authentication-keyid 10

3.     Configure the switch:

# Enable the SNTP service.

<Switch> system-view

[Switch] sntp enable

# Enable SNTP authentication on the switch.

[Switch] sntp authentication enable

# Configure an SNTP authentication key, with the key ID of 10 and key value of aNiceKey. Input the key in plain text.

[Switch] sntp authentication-keyid 10 authentication-mode md5 simple aNiceKey

# Specify the key as a trusted key.

[Switch] sntp reliable authentication-keyid 10

# Specify the AC as the NTP server of the switch, and associate the server with key 10.

[Switch] sntp unicast-server 1.0.1.11 authentication-keyid 10

4.     Verify the configuration:

# Verify that an SNTP association has been established between the switch and the AC, and the switch has synchronized to the AC.

[Switch] display sntp sessions

NTP server     Stratum   Version    Last receive time

1.0.1.11        2         4          Tue, May 17 2011  9:11:20.833 (Synced)

 


Configuring SNMP

Overview

Simple Network Management Protocol (SNMP) is an Internet standard protocol widely used for a management station to access and operate the devices on a network, regardless of their vendors, physical characteristics, and interconnect technologies.

SNMP enables network administrators to read and set the variables on managed devices for state monitoring, troubleshooting, statistics collection, and other management purposes.

SNMP framework

The SNMP framework contains the following elements:

·     SNMP manager—Works on an NMS to monitor and manage the SNMP-capable devices in the network.

·     SNMP agent—Works on a managed device to receive and handle requests from the NMS, and sends notifications to the NMS when events, such as an interface state change, occur.

·     Management Information Base (MIB)—Specifies the variables (for example, interface status and CPU usage) maintained by the SNMP agent for the SNMP manager to read and set.

Figure 34 Relationship between NMS, agent, and MIB

 

MIB and view-based MIB access control

A MIB stores variables called "nodes" or "objects" in a tree hierarchy and identifies each node with a unique OID. An OID is a dotted numeric string that uniquely identifies the path from the root node to a leaf node. For example, object B in Figure 35 is uniquely identified by the OID {1.2.1.1}.

Figure 35 MIB tree

 

A MIB view represents a set of MIB objects (or MIB object hierarchies) with certain access privileges and is identified by a view name. The MIB objects included in the MIB view are accessible while those excluded from the MIB view are inaccessible.

A MIB view can have multiple view records each identified by a view-name oid-tree pair.

You control access to the MIB by assigning MIB views to SNMP groups or communities.

SNMP operations

SNMP provides the following basic operations:

·     Get—NMS retrieves the SNMP object nodes in an agent MIB.

·     Set—NMS modifies the value of an object node in an agent MIB.

·     Notification—SNMP agent sends traps or informs to report events to the NMS. The difference between these two types of notification is that informs require acknowledgment but traps do not. Traps are available in SNMPv1, SNMPv2c, and SNMPv3. Informs are available only in SNMPv2c and SNMPv3.

Protocol versions

An NMS and an SNMP agent must use the same SNMP version to communicate with each other.

·     SNMPv1—Uses community names for authentication. To access an SNMP agent, an NMS must use the same community name as set on the SNMP agent. If the community name used by the NMS differs from the community name set on the agent, the NMS cannot establish an SNMP session to access the agent or receive traps from the agent.

·     SNMPv2c—Uses community names for authentication. SNMPv2c is compatible with SNMPv1, but supports more operation types, data types, and error codes.

·     SNMPv3—Uses a user-based security model (USM) to secure SNMP communication. You can configure authentication and privacy mechanisms to authenticate and encrypt SNMP packets for integrity, authenticity, and confidentiality.

Access control modes

SNMP uses the following modes to control access to MIB objects:

·     View-based Access Control ModelThe VACM mode controls access to MIB objects by assigning MIB views to SNMP communities or users.

·     Role based access controlThe RBAC mode controls access to MIB objects by assigning user roles to SNMP communities or users.

?     SNMP communities or users have read and write access to all MIB objects if they use the predefined network-admin or level-15 user role.

?     SNMP communities or users have read-only access to all MIB objects if they use the predefined network-operator user role.

?     SNMP communities or users with a user-defined user role have access rights to MIB objects as specified by the rule command.

If you create the same SNMP community or user with both modes multiple times, the most recent configuration takes effect. For more information about RBAC, see Fundamentals Command Reference.

For an NMS to access an agent:

·     The RBAC mode requires the user role bound to a community name or username to have the same access right to MIB objects as the NMS.

·     The VACM mode requires only the access right from the NMS to MIB objects.

RBAC mode controls access on a per MIB object basis, and VACM mode controls access on a MIB view basis. As a best practice to enhance MIB security, use the RBAC mode.

FIPS compliance

The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features, commands, and parameters might differ in FIPS mode and non-FIPS mode. For more information about FIPS mode, see Security Configuration Guide.

Configuring SNMP basic parameters

SNMPv3 differs from SNMPv1 and SNMPv2c in many ways. Their configuration procedures are described in separate sections.

Configuring SNMPv1 or SNMPv2c basic parameters

Only users with the network-admin or level-15 user role can create SNMPv1 or SNMPv2c communities, users, or groups. Users with other user roles cannot create SNMPv1 or SNMPv2c communities, users, or groups even if these roles are granted access to related commands or commands of the SNMPv1 or SNMPv2c feature.

To configure SNMPv1 or SNMPv2c basic parameters:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     (Optional.) Enable the SNMP agent.

snmp-agent

By default, the SNMP agent is disabled.

The SNMP agent is enabled when you use any command that begins with snmp-agent except for the snmp-agent calculate-password command.

3.     (Optional.) Configure the system contact.

snmp-agent sys-info contact sys-contact

The default system contact is New H3C Technologies Co., Ltd..

4.     (Optional.) Configure the system location.

snmp-agent sys-info location sys-location

The default system location is Hangzhou, China.

5.     Enable SNMPv1 or SNMPv2c.

snmp-agent sys-info version { all | { v1 | v2c } *}

By default, SNMPv3 is enabled.

6.     (Optional.) Change the local engine ID.

snmp-agent local-engineid engineid

By default, the local engine ID is the company ID plus the device ID.

7.     (Optional.) Create or update a MIB view.

snmp-agent mib-view { excluded | included } view-name oid-tree [ mask mask-value ]

By default, the MIB view ViewDefault is predefined. In this view, all the MIB objects in the iso subtree but the snmpUsmMIB, snmpVacmMIB, and snmpModules.18 subtrees are accessible.

Each view-name oid-tree pair represents a view record. If you specify the same record with different MIB sub-tree masks multiple times, the most recent configuration takes effect. Except for the four sub-trees in the default MIB view, you can create up to 16 unique MIB view records.

8.     Configure the SNMP access right.

·     (Method 1.) Create an SNMP community:
In VACM mode:

snmp-agent community { read | write } [ simple | cipher ] community-name [ mib-view view-name ] [ acl { acl-number | name acl-name } | acl ipv6 { ipv6-acl-number | name ipv6-acl-name } ] *

In RBAC mode:
snmp-agent community [ simple | cipher ] community-name user-role role-name [ acl { acl-number | name acl-name } | acl ipv6 { ipv6-acl-number | name ipv6-acl-name } ] *

·     (Method 2.) Create an SNMPv1/v2c group, and add users to the group:

a.     snmp-agent group { v1 | v2c } group-name [ read-view view-name ] [ write-view view-name ] [ notify-view view-name ] [ acl { acl-number | name acl-name } | acl ipv6 { ipv6-acl-number | name ipv6-acl-name } ] *

b.     snmp-agent usm-user { v1 | v2c } user-name group-name [ acl { acl-number | name acl-name } | acl ipv6 { ipv6-acl-number | name ipv6-acl-name } ] *

By default, no SNMP group or SNMP community exists.

The username in method 2 has the same purpose as the community name in method 1. Whichever method you use, make sure the configured name is the same as the community name on the NMS.

9.     (Optional.) Create an SNMP context.

snmp-agent context context-name

By default, no SNMP context is configured on the device.

10.     (Optional.) Map an SNMP community to an SNMP context.

snmp-agent community-map community-name context context-name

By default, no mapping between an SNMP community and an SNMP context exists on the device.

11.     (Optional.) Configure the maximum SNMP packet size (in bytes) that the SNMP agent can handle.

snmp-agent packet max-size byte-count

By default, the maximum size of SNMP packets that an SNMP agent can process is 1500 bytes.

12.     Specify the UDP port for receiving SNMP packets.

snmp-agent port port-num

By default, the device uses UDP port 161 for receiving SNMP packets.

 

Configuring SNMPv3 basic parameters

Only users with the network-admin or level-15 user role can create SNMPv3 users or groups. Users with other user roles cannot create SNMPv3 users or groups even if these roles are granted access to related commands or commands of the SNMPv3 feature.

SNMPv3 users are managed in groups. All SNMPv3 users in a group share the same security model, but can use different authentication and encryption key settings. To implement a security model for a user and avoid SNMP communication failures, make sure the security model configuration for the group and the security key settings for the user are compliant with Table 7 and match the settings on the NMS.

Table 7 Basic security setting requirements for different security models

Security model

Security model keyword for the group

Security key settings for the user

Remarks

Authentication with privacy

privacy

Authentication key, encryption key

If the authentication key or the encryption key is not configured, SNMP communication will fail.

Authentication without privacy

authentication

Authentication key

If no authentication key is configured, SNMP communication will fail.

The encryption key (if any) for the user does not take effect.

No authentication, no privacy

Neither authentication nor privacy

None

The authentication and encryption keys, if configured, do not take effect.

 

To configure SNMPv3 basic parameters:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     (Optional.) Enable the SNMP agent.

snmp-agent

By default, the SNMP agent is disabled.

The SNMP agent is enabled when you use any command that begins with snmp-agent except for the snmp-agent calculate-password command.

3.     (Optional.) Configure the system contact.

snmp-agent sys-info contact sys-contact

The default system contact is New H3C Technologies Co., Ltd..

4.     (Optional.) Configure the system location.

snmp-agent sys-info location sys-location

The default system location is Hangzhou, China.

5.     Enable SNMPv3.

snmp-agent sys-info version v3

By default, SNMPv3 is enabled.

6.     (Optional.) Change the local engine ID.

snmp-agent local-engineid engineid

By default, the local engine ID is the company ID plus the device ID.

* IMPORTANT:

After you change the local engine ID, the existing SNMPv3 users and encrypted keys become invalid, and you must reconfigure them.

7.     (Optional.) Configure a remote engine ID.

snmp-agent remote { ip-address | ipv6 ipv6-address } engineid engineid

By default, no remote engine ID is configured.

To send informs to an SNMPv3 NMS, you must configure the SNMP engine ID of the NMS.

8.     (Optional.) Create or update a MIB view.

snmp-agent mib-view { excluded | included } view-name oid-tree [ mask mask-value ]

By default, the MIB view ViewDefault is predefined. In this view, all the MIB objects in the iso subtree but the snmpUsmMIB, snmpVacmMIB, and snmpModules.18 subtrees are accessible.

Each view-name oid-tree pair represents a view record. If you specify the same record with different MIB sub-tree masks multiple times, the most recent configuration takes effect. Except for the four sub-trees in the default MIB view, you can create up to 16 unique MIB view records.

9.     (Optional.) Create an SNMPv3 group.

snmp-agent group v3 group-name [ authentication | privacy ] [ read-view view-name ] [ write-view view-name ] [ notify-view view-name ] [ acl { acl-number | name acl-name } | acl ipv6 { ipv6-acl-number | name ipv6-acl-name } ] *

By default, no SNMP group exists.

10.     (Optional.) Calculate the encrypted form for a key in plaintext form.

snmp-agent calculate-password plain-password mode { 3desmd5 | 3dessha | md5 | sha } { local-engineid | specified-engineid engineid }

N/A

11.     Create an SNMPv3 user.

·     In VACM mode:
snmp-agent usm-user v3 user-name group-name [ remote { ip-address | ipv6 ipv6-address } [ { cipher | simple } authentication-mode { md5 | sha } auth-password [ privacy-mode { aes128 | 3des | des56 } priv-password ] ] [ acl { acl-number | name acl-name } | acl ipv6 { ipv6-acl-number | name ipv6-acl-name } ] *

·     In RBAC mode:
snmp-agent usm-user v3 user-name user-role role-name [ remote { ip-address | ipv6 ipv6-address } ] [ { cipher | simple } authentication-mode { md5 | sha } auth-password [ privacy-mode { aes128 | 3des | des56 } priv-password ] ] [ acl { acl-number | name acl-name } | acl ipv6 { ipv6-acl-number | name ipv6-acl-name } ] *

If the cipher keyword is specified, the arguments auth-password and priv-password are used as encrypted keys.

To send informs to an SNMPv3 NMS, you must configure the remote ip-address option to specify the IP address of the NMS.

12.     (Optional.) Assign a user role to an SNMPv3 user created in RBAC mode.

snmp-agent usm-user user-name v3 user-role role-name

By default, no SNMPv3 users are configured in RBAC mode.

13.     (Optional.) Create an SNMP context.

snmp-agent context context-name

By default, no SNMP context is configured on the device.

14.     (Optional.) Configure the maximum SNMP packet size (in bytes) that the SNMP agent can handle.

snmp-agent packet max-size byte-count

By default, the maximum size of SNMP packets that an SNMP agent can process is 1500 bytes.

15.     (Optional.) Specify the UDP port for receiving SNMP packets.

snmp-agent port port-num

By default, the device uses UDP port 161 for receiving SNMP packets.

 

Configuring SNMP logging

Enable SNMP logging only if necessary. SNMP logging is memory-intensive and might impact device performance.

The SNMP agent logs Get requests, Set requests, Set responses, SNMP notifications, and SNMP authentication failures, but does not log Get responses.

·     Get operation—The agent logs the IP address of the NMS, name of the accessed node, and node OID.

·     Set operation—The agent logs the NMS' IP address, name of accessed node, node OID, variable value, and error code and index for the Set operation.

·     Notification tracking—The agent logs the SNMP notifications after sending them to the NMS.

·     SNMP authentication failureThe agent logs related information when an NMS fails to be authenticated by the agent.

The SNMP module sends these logs to the information center. You can configure the information center to output these messages to certain destinations, such as the console and the log buffer. The total output size for the node field (MIB node name) and the value field (value of the MIB node) in each log entry is 1024 bytes. If this limit is exceeded, the information center truncates the data in the fields. For more information about the information center, see "Configuring the information center."

To configure SNMP logging:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     (Optional.) Enable SNMP logging.

snmp-agent log { all | authfail | get-operation | set-operation }

By default, SNMP logging is disabled.

3.     (Optional.) Enable SNMP notification logging.

snmp-agent trap log

By default, SNMP notification logging is disabled.

 

Configuring SNMP notifications

The SNMP Agent sends notifications (traps and informs) to inform the NMS of significant events, such as link state changes and user logins or logouts. Unless otherwise stated, the trap keyword in the command line includes both traps and informs.

Enabling SNMP notifications

Enable an SNMP notification only if necessary. SNMP notifications are memory-intensive and might affect device performance.

To generate linkUp or linkDown notifications when the link state of an interface changes, you must perform the following tasks:

·     Enable linkUp or linkDown notification globally by using the snmp-agent trap enable standard [ linkdown | linkup ] * command.

·     Enable linkUp or linkDown notification on the interface by using the enable snmp trap updown command.

After you enable notifications for a module, whether the module generates notifications also depends on the configuration of the module. For more information, see the configuration guide for each module.

To enable SNMP notifications:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable notifications globally.

snmp-agent trap enable [ configuration | protocol | standard [ authentication | coldstart | linkdown | linkup | warmstart ] * | system ]

By default, SNMP configuration notifications, standard notifications, and system notifications are enabled. Whether other SNMP notifications are enabled varies by modules.

3.     Enter interface view.

interface interface-type interface-number

N/A

4.     Enable link state notifications.

enable snmp trap updown

By default, link state notifications are enabled.

 

Configuring the SNMP agent to send notifications to a host

You can configure the SNMP agent to send notifications as traps or informs to a host, typically an NMS, for analysis and management. Traps are less reliable and use fewer resources than informs, because an NMS does not send an acknowledgment when it receives a trap.

Configuration guidelines

When network congestion occurs or the destination is not reachable, the SNMP agent buffers notifications in a queue. You can configure the queue size and the notification lifetime (the maximum time that a notification can stay in the queue). A notification is deleted when its lifetime expires. When the notification queue is full, the oldest notifications are automatically deleted.

You can extend standard linkUp/linkDown notifications to include interface description and interface type, but must make sure the NMS supports the extended SNMP messages.

To send informs, make sure:

·     The SNMP agent and the NMS use SNMPv2c or SNMPv3.

·     If SNMPv3 is used, you must configure the SNMP engine ID of the NMS when you configure SNMPv3 basic settings. Also, specify the IP address of the SNMP engine when you create the SNMPv3 user.

Configuration prerequisites

Configure the SNMP agent with the same basic SNMP settings as the NMS. If SNMPv1 or SNMPv2c is used, you must configure a community name. If SNMPv3 is used, you must configure an SNMPv3 user, a MIB view, and a remote SNMP engine ID associated with the SNMPv3 user for notifications.

Make sure the SNMP agent and the NMS can reach each other.

Configuration procedure

To configure the SNMP agent to send notifications to a host:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure a target host.

·     Send traps to the target host:
snmp-agent target-host trap address udp-domain { ip-address | ipv6 ipv6-address } [ udp-port port-number ] params securityname security-string [ v1 | v2c | v3 [ authentication | privacy ] ]

·     Send informs to the target host:
snmp-agent target-host inform address udp-domain { ip-address | ipv6 ipv6-address } [ udp-port port-number ] params securityname security-string { v2c | v3 [ authentication | privacy ] }

By default, no target host is configured.

3.     (Optional.) Configure a source address for notifications.

snmp-agent { inform | trap } source interface-type { interface-number | interface-number.subnumber }

By default, SNMP uses the IP address of the outgoing routed interface as the source IP address.

4.     (Optional.) Enable extended linkUp/linkDown notifications.

snmp-agent trap if-mib link extended

By default, the SNMP agent sends standard linkUp/linkDown notifications.

5.     (Optional.) Configure the notification queue size.

snmp-agent trap queue-size size

By default, the notification queue can hold 100 notification messages.

6.     (Optional.) Configure the notification lifetime.

snmp-agent trap life seconds

The default notification lifetime is 120 seconds.

 

Displaying the SNMP settings

Execute display commands in any view.

 

Task

Command

Display SNMP agent system information, including the contact, physical location, and SNMP version.

display snmp-agent sys-info [ contact | location | version ] *

Display SNMP agent statistics.

display snmp-agent statistics

Display the local engine ID.

display snmp-agent local-engineid

Display SNMP group information.

display snmp-agent group [ group-name ]

Display remote engine IDs.

display snmp-agent remote [ ip-address | ipv6 ipv6-address ]

Display basic information about the notification queue.

display snmp-agent trap queue

Display SNMP notifications enabling status for modules.

display snmp-agent trap-list

Display SNMPv3 user information.

display snmp-agent usm-user [ engineid engineid | username user-name | group group-name ] *

Display SNMPv1 or SNMPv2c community information.

display snmp-agent community [ read | write ]

Display MIB view information.

display snmp-agent mib-view [ exclude | include | viewname view-name ]

Display SNMP MIB node information.

display snmp-agent mib-node [ details | index-node | trap-node | verbose ]

Display an SNMP context.

display snmp-agent context [ context-name ]

 

SNMPv1/SNMPv2c configuration example

The SNMPv1 configuration procedure is the same as the SNMPv2c configuration procedure. This example uses SNMPv1.

Network requirements

As shown in Figure 36, the NMS (1.1.1.2/24) uses SNMPv1 to manage the SNMP agent (1.1.1.1/24), and the agent automatically sends notifications to report events to the NMS.

Figure 36 Network diagram

 

Configuration procedure

1.     Configure the SNMP agent:

# Configure the IP address of the agent and make sure the agent and the NMS can reach each other. (Details not shown.)

# Specify SNMPv1, and create the read-only community public and the read and write community private.

<AC> system-view

[AC] snmp-agent sys-info version v1

[AC] snmp-agent community read public

[AC] snmp-agent community write private

# Configure contact and physical location information for the agent.

[AC] snmp-agent sys-info contact Mr.Wang-Tel:3306

[AC] snmp-agent sys-info location telephone-closet,3rd-floor

# Enable SNMP notifications, specify the NMS at 1.1.1.2 as an SNMP trap destination, and use public as the community name. (To make sure the NMS can receive traps, specify the same SNMP version in the snmp-agent target-host command as is configured on the NMS.)

[AC] snmp-agent trap enable

[AC] snmp-agent target-host trap address udp-domain 1.1.1.2 params securityname public v1

2.     Configure the SNMP NMS:

?     Specify SNMPv1.

?     Create the read-only community public, and create the read and write community private.

?     Set the timeout timer and maximum number of retries as needed.

For information about configuring the NMS, see the NMS manual.

 

 

NOTE:

The SNMP settings on the agent and the NMS must match.

 

Verifying the configuration

# Try to get the MTU value of NULL0 interface from the agent. The attempt succeeds.

Send request to 1.1.1.1/161 ...

Protocol version: SNMPv1

Operation: Get

Request binding:

1: 1.3.6.1.2.1.2.2.1.4.135471

Response binding:

1: Oid=ifMtu.135471 Syntax=INT Value=1500

Get finished

# Use a wrong community name to get the value of a MIB node on the agent. You can see an authentication failure trap on the NMS.

1.1.1.1/2934 V1 Trap = authenticationFailure

SNMP Version = V1

Community = public

Command = Trap

Enterprise = 1.3.6.1.4.1.43.1.16.4.3.50

GenericID = 4

SpecificID = 0

Time Stamp = 8:35:25.68

SNMPv3 configuration example

Network requirements

As shown in Figure 37, the NMS (1.1.1.2/24) uses SNMPv3 to monitor and manage the agent (1.1.1.1/24). The agent automatically sends notifications to report events to the NMS. The default UDP port 162 is used for SNMP notifications.

The NMS and the agent perform authentication when they establish an SNMP session. The authentication algorithm is SHA-1 and the authentication key is 123456TESTauth&!. The NMS and the agent also encrypt the SNMP packets between them by using the AES algorithm and the encryption key 123456TESTencr&!.

Figure 37 Network diagram

 

Configuration procedure

Configuring SNMPv3 in RBAC mode

1.     Configure the agent:

# Assign IP address 1.1.1.1/24 to the agent and make sure the agent and the NMS can reach each other. (Details not shown.)

# Create user role test, and assign test read-only access to the objects under the snmpMIB subtree (OID: 1.3.6.1.6.3.1), including the linkUp and linkDown objects.

<AC> system-view

[AC] role name test

[AC-role-test] rule 1 permit read oid 1.3.6.1.6.3.1

# Assign user role test read-only access to the system subtree (OID: 1.3.6.1.2.1.1) and read-write access to the interfaces subtree (OID: 1.3.6.1.2.1.2).

[AC-role-test] rule 2 permit read oid 1.3.6.1.2.1.1

[AC-role-test] rule 3 permit read write oid 1.3.6.1.2.1.2

[AC-role-test] quit

# Create SNMPv3 user RBACtest. Assign user role test to RBACtest. Set the authentication algorithm to sha, authentication key to 123456TESTauth&!, encryption algorithm to aes128, and encryption key to 123456TESTencr&!.

[AC] snmp-agent usm-user v3 RBACtest user-role test simple authentication-mode sha 123456TESTauth&! privacy-mode aes128 123456TESTencr&!

# Configure contact and physical location information for the agent.

[AC] snmp-agent sys-info contact Mr.Wang-Tel:3306

[AC] snmp-agent sys-info location telephone-closet,3rd-floor

# Enable notifications on the agent. Specify the NMS at 1.1.1.2 as the target host, and RBACtest as the username.

[AC] snmp-agent trap enable

[AC] snmp-agent target-host trap address udp-domain 1.1.1.2 params securityname RBACtest v3 privacy

2.     Configure the SNMP NMS:

?     Specify SNMPv3.

?     Create SNMPv3 user RBACtest.

?     Enable authentication and privacy.

?     Specify the SHA-1 authentication algorithm and AES encryption algorithm.

?     Set the authentication key to 123456TESTauth&! and the encryption key to 123456TESTencr&!.

?     Set the timeout timer and maximum number of retries.

For information about configuring the NMS, see the NMS manual.

 

 

NOTE:

The SNMP settings on the agent and the NMS must match.

 

Configuring SNMPv3 in VACM mode

1.     Configure the agent:

# Assign IP address 1.1.1.1/24 to the agent, and make sure the agent and the NMS can reach each other. (Details not shown.)

# Create MIB view test and include subtree snmpMIB in the view. Create SNMPv3 group managev3group and assign managev3group read-write access to objects in the test view, including the linkUp and linkDown objects.

<AC> system-view

[AC] undo snmp-agent mib-view ViewDefault

[AC] snmp-agent mib-view included test snmpMIB

[AC] snmp-agent group v3 managev3group privacy read-view test write-view test

# Include the system subtree (OID: 1.3.6.1.2.1.1) and interfaces subtree (OID: 1.3.6.1.2.1.2) in the test view. Assign SNMPv3 group managev3group write access to the test view.

[AC] snmp-agent mib-view included test 1.3.6.1.2.1.1

[AC] snmp-agent mib-view included test 1.3.6.1.2.1.2

[AC] snmp-agent group v3 managev3group privacy write-view test

# Add user VACMtest to SNMPv3 group managev3group, and set the authentication algorithm to sha, authentication key to 123456TESTauth&!, encryption algorithm to aes128, and encryption key to 123456TESTencr&!.

[AC] snmp-agent usm-user v3 VACMtest managev3group simple authentication-mode sha 123456TESTauth&! privacy-mode aes128 123456TESTencr&!

# Configure contact and physical location information for the agent.

[AC] snmp-agent sys-info contact Mr.Wang-Tel:3306

[AC] snmp-agent sys-info location telephone-closet,3rd-floor

# Enable notifications on the agent. Specify the NMS at 1.1.1.2 as the target host, and VACMtest as the username.

[AC] snmp-agent trap enable

[AC] snmp-agent target-host trap address udp-domain 1.1.1.2 params securityname VACMtest v3 privacy

2.     Configure the SNMP NMS:

?     Specify SNMPv3.

?     Create SNMPv3 user VACMtest.

?     Enable authentication and privacy.

?     Specify the SHA-1 authentication algorithm and AES encryption algorithm.

?     Set the authentication key to 123456TESTauth&! and the encryption key to 123456TESTencr&!.

?     Set the timeout timer and maximum number of retries.

For information about configuring the NMS, see the NMS manual.

 

 

NOTE:

The SNMP settings on the agent and the NMS must match.

 

Verifying the configuration

·     Use username RBACtest to access the agent.

# Retrieve the value of the sysName node. The value Agent is returned.

# Set the value for the sysName node to Sysname. The operation fails because the NMS does not have write access to the node.

# Shut down or bring up an interface on the agent. The NMS receives linkUP (OID: 1.3.6.1.6.3.1.1.5.4) or linkDown (OID: 1.3.6.1.6.3.1.1.5.3) notifications.

·     Use username VACMtest to access the agent.

# Retrieve the value of the sysName node. The value Agent is returned.

# Set the value for the sysName node to Sysname. The operation succeeds.

# Shut down or bring up an interface on the agent. The NMS receives linkUP (OID: 1.3.6.1.6.3.1.1.5.4) or linkDown (OID: 1.3.6.1.6.3.1.1.5.3) notifications.


Configuring RMON

Overview

Remote Network Monitoring (RMON) is an enhancement to SNMP. It enables proactive remote monitoring and management of network devices and subnets. An RMON monitor periodically or continuously collects traffic statistics for the network attached to a port on the managed device. The managed device can automatically send a notification when a statistic crosses an alarm threshold, so the NMS does not need to constantly poll MIB variables and compare the results.

RMON uses SNMP notifications to notify NMSs of various alarm conditions such as broadcast traffic threshold exceeded. In contrast, SNMP reports function and interface operating status changes such as link up, link down, and module failure. For more information about SNMP notifications, see "Configuring SNMP."

H3C devices provide an embedded RMON agent as the RMON monitor. An NMS can perform basic SNMP operations to access the RMON MIB.

RMON groups

Among standard RMON groups, H3C implements the statistics group, history group, event group, alarm group, probe configuration group, and user history group. H3C also implements a private alarm group, which enhances the standard alarm group. The probe configuration group and user history group are not configurable from the CLI. To configure these two groups, you must access the MIB.

Statistics group

The statistics group samples traffic statistics for monitored Ethernet interfaces and stores the statistics in the Ethernet statistics table (ethernetStatsTable). The statistics include:

·     Number of collisions.

·     CRC alignment errors.

·     Number of undersize or oversize packets.

·     Number of broadcasts.

·     Number of multicasts.

·     Number of bytes received.

·     Number of packets received.

The statistics in the Ethernet statistics table are cumulative sums.

History group

The history group periodically samples traffic statistics on interfaces and saves the history samples in the history table (etherHistoryTable). The statistics include:

·     Bandwidth utilization.

·     Number of error packets.

·     Total number of packets.

The history table stores traffic statistics collected for each sampling interval.

Event group

The event group controls the generation and notifications of events triggered by the alarms defined in the alarm group and the private alarm group. The following are RMON alarm event handling methods:

·     Log—Logs event information (including event time and description) in the event log table so the management device can get the logs through SNMP.

·     Trap—Sends an SNMP notification when the event occurs.

·     Log-Trap—Logs event information in the event log table and sends an SNMP notification when the event occurs.

·     NoneTakes no actions.

Alarm group

The RMON alarm group monitors alarm variables, such as the count of incoming packets (etherStatsPkts) on an interface. After you create an alarm entry, the RMON agent samples the value of the monitored alarm variable regularly. If the value of the monitored variable is greater than or equal to the rising threshold, a rising alarm event is triggered. If the value of the monitored variable is smaller than or equal to the falling threshold, a falling alarm event is triggered. The event group defines the action to take on the alarm event.

If an alarm entry crosses a threshold multiple times in succession, the RMON agent generates an alarm event only for the first crossing. For example, if the value of a sampled alarm variable crosses the rising threshold multiple times before it crosses the falling threshold, only the first crossing triggers a rising alarm event, as shown in Figure 38.

Figure 38 Rising and falling alarm events

 

Private alarm group

The private alarm group enables you to perform basic math operations on multiple variables, and compare the calculation result with the rising and falling thresholds.

The RMON agent samples variables and takes an alarm action based on a private alarm entry as follows:

1.     Samples the private alarm variables in the user-defined formula.

2.     Processes the sampled values with the formula.

3.     Compares the calculation result with the predefined thresholds, and then takes one of the following actions:

?     Triggers the event associated with the rising alarm event if the result is equal to or greater than the rising threshold.

?     Triggers the event associated with the falling alarm event if the result is equal to or less than the falling threshold.

If a private alarm entry crosses a threshold multiple times in succession, the RMON agent generates an alarm event only for the first crossing. For example, if the value of a sampled alarm variable crosses the rising threshold multiple times before it crosses the falling threshold, only the first crossing triggers a rising alarm event.

Sample types for the alarm group and the private alarm group

The RMON agent supports the following sample types:

·     absolute—RMON compares the value of the monitored variable with the rising and falling thresholds at the end of the sampling interval.

·     delta—RMON subtracts the value of the monitored variable at the previous sample from the current value, and then compares the difference with the rising and falling thresholds.

Protocols and standards

·     RFC 4502, Remote Network Monitoring Management Information Base Version 2

·     RFC 2819, Remote Network Monitoring Management Information Base Status of this Memo

Configuring the RMON statistics function

RMON implements the statistics function through the Ethernet statistics group and the history group. The statistics function is available only for Layer 2 and Layer 3 Ethernet interfaces.

The Ethernet statistics group provides the cumulative statistic for a variable from the time the statistics entry is created to the current time. For more information about the configuration, see "Creating an RMON Ethernet statistics entry."

The history group provides statistics that are sampled for a variable for each sampling interval. The history group uses the history control table to control sampling, and it stores samples in the history table. For more information about the configuration, see "Creating an RMON history control entry."

Creating an RMON Ethernet statistics entry

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter Ethernet interface view.

interface interface-type interface-number

N/A

3.     Create an entry for the interface in the RMON statistics table.

rmon statistics entry-number [ owner text ]

By default, the RMON statistics table does not contain entries.

You can create one statistics entry for each Ethernet interface, and a maximum of 100 statistics entries on the device. After the entry limit is reached, you cannot add new entries.

 

Creating an RMON history control entry

You can configure multiple history control entries for one interface, but you must make sure their entry numbers and sampling intervals are different.

You can create a history control entry successfully even if the specified bucket size exceeds the available history table size. RMON will set the bucket size as closely to the expected bucket size as possible.

To create an RMON history control entry:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter Ethernet interface view.

interface interface-type interface-number

N/A

3.     Create an entry for the interface in the RMON history control table.

rmon history entry-number buckets number interval sampling-interval [ owner text ]

By default, the RMON history control table does not contain entries.

You can create a maximum of 100 history control entries.

 

Configuring the RMON alarm function

When you configure the RMON alarm function, follow these guidelines:

·     To send notifications to the NMS when an alarm is triggered, configure the SNMP agent as described in "Configuring SNMP" before configuring the RMON alarm function.

·     For a new event, alarm, or private alarm entry to be created:

?     The entry must not have the same set of parameters as an existing entry.

?     The maximum number of entries is not reached.

Table 8 shows the parameters to be compared for duplication and the entry limits.

Table 8 RMON configuration restrictions

Entry

Parameters to be compared

Maximum number of entries

Event

·     Event description (description string)

·     Event type (log, trap, logtrap, or none)

·     Community name (security-string)

60

Alarm

·     Alarm variable (alarm-variable)

·     Sampling interval (sampling-interval)

·     Sample type (absolute or delta)

·     Rising threshold (threshold-value1)

·     Falling threshold (threshold-value2)

60

Private alarm

·     Alarm variable formula (prialarm-formula)

·     Sampling interval (sampling-interval)

·     Sample type (absolute or delta)

·     Rising threshold (threshold-value1)

·     Falling threshold (threshold-value2)

50

 

To configure the RMON alarm function:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     (Optional.) Create an event entry in the event table.

rmon event entry-number [ description string ] { log | log-trap security-string | none | trap security-string } [ owner text ]

By default, the RMON event table does not contain entries.

3.     Create an entry in the alarm table or private alarm table.

·     Create an entry in the alarm table:
rmon alarm
entry-number alarm-variable sampling-interval { absolute | delta } [ startup-alarm { falling | rising | rising-falling } ] rising-threshold threshold-value1 event-entry1 falling-threshold threshold-value2 event-entry2 [ owner text ]

·     Create an entry in the private alarm table:
rmon prialarm
entry-number prialarm-formula prialarm-des sampling-interval { absolute | delta } [ startup-alarm { falling | rising | rising-falling } ] rising-threshold threshold-value1 event-entry1 falling-threshold threshold-value2 event-entry2 entrytype { forever | cycle cycle-period } [ owner text ]

By default, the RMON alarm table and the private alarm table do not contain entries.

You can associate an alarm with an event that has not been created yet. The alarm will trigger the event only after the event is created.

 

Displaying and maintaining RMON settings

Execute display commands in any view.

 

Task

Command

Display RMON statistics.

display rmon statistics [ interface-type interface-number]

Display RMON history control entries and history samples.

display rmon history [ interface-type interface-number ]

Display RMON alarm entries.

display rmon alarm [ entry-number ]

Display RMON private alarm entries.

display rmon prialarm [ entry-number ]

Display RMON event entries.

display rmon event [ entry-number ]

Display log information for event entries.

display rmon eventlog [ entry-number ]

 

RMON configuration examples

Ethernet statistics group configuration example

Network requirements

As shown in Figure 39, create an RMON Ethernet statistics entry on the AC to gather cumulative traffic statistics for GigabitEthernet 1/0/1.

Figure 39 Network diagram

 

Configuration procedure

# Create an RMON Ethernet statistics entry for GigabitEthernet 1/0/1.

<AC> system-view

[AC] interface gigabitethernet 1/0/1

[AC-GigabitEthernet1/0/1] rmon statistics 1 owner user1

# Display statistics collected for GigabitEthernet 1/0/1.

<AC> display rmon statistics gigabitethernet 1/0/1

EtherStatsEntry 1 owned by user1 is VALID.

  Interface : GigabitEthernet1/0/1<ifIndex.3>

  etherStatsOctets         : 21657     , etherStatsPkts          : 307

  etherStatsBroadcastPkts  : 56        , etherStatsMulticastPkts : 34

  etherStatsUndersizePkts  : 0         , etherStatsOversizePkts  : 0

  etherStatsFragments      : 0         , etherStatsJabbers       : 0

  etherStatsCRCAlignErrors : 0         , etherStatsCollisions    : 0

  etherStatsDropEvents (insufficient resources): 0

  Incoming packets by size:

  64     : 235       ,  65-127  : 67        ,  128-255  : 4

  256-511: 1         ,  512-1023: 0         ,  1024-1518: 0

# Get the traffic statistics from the NMS through SNMP. (Details not shown.)

History group configuration example

Network requirements

As shown in Figure 40, create an RMON history control entry on the AC to sample traffic statistics for GigabitEthernet 1/0/1 every minute.

Figure 40 Network diagram

 

Configuration procedure

# Create an RMON history control entry to sample traffic statistics every minute for GigabitEthernet 1/0/1. Retain a maximum of eight samples for the interface in the history statistics table.

<AC> system-view

[AC] interface gigabitethernet 1/0/1

[AC-GigabitEthernet1/0/1] rmon history 1 buckets 8 interval 60 owner user1

# Display the history statistics collected for GigabitEthernet 1/0/1.

[AC-GigabitEthernet1/0/1] display rmon history

HistoryControlEntry 1 owned by user1 is VALID

  Sampled interface     : GigabitEthernet1/0/1<ifIndex.3>

  Sampling interval     : 60(sec) with 8 buckets max

  Sampling record 1 :

    dropevents        : 0         , octets               : 834

    packets           : 8         , broadcast packets    : 1

    multicast packets : 6         , CRC alignment errors : 0

    undersize packets : 0         , oversize packets     : 0

    fragments         : 0         , jabbers              : 0

    collisions        : 0         , utilization          : 0

  Sampling record 2 :

    dropevents        : 0         , octets               : 962

    packets           : 10        , broadcast packets    : 3

    multicast packets : 6         , CRC alignment errors : 0

    undersize packets : 0         , oversize packets     : 0

    fragments         : 0         , jabbers              : 0

    collisions        : 0         , utilization          : 0

  Sampling record 3 :

    dropevents        : 0         , octets               : 830

    packets           : 8         , broadcast packets    : 0

    multicast packets : 6         , CRC alignment errors : 0

    undersize packets : 0         , oversize packets     : 0

    fragments         : 0         , jabbers              : 0

    collisions        : 0         , utilization          : 0

  Sampling record 4 :

    dropevents        : 0         , octets               : 933

    packets           : 8         , broadcast packets    : 0

    multicast packets : 7         , CRC alignment errors : 0

    undersize packets : 0         , oversize packets     : 0

    fragments         : 0         , jabbers              : 0

    collisions        : 0         , utilization          : 0

  Sampling record 5 :

    dropevents        : 0         , octets               : 898

    packets           : 9         , broadcast packets    : 2

    multicast packets : 6         , CRC alignment errors : 0

    undersize packets : 0         , oversize packets     : 0

    fragments         : 0         , jabbers              : 0

    collisions        : 0         , utilization          : 0

  Sampling record 6 :

    dropevents        : 0         , octets               : 898

    packets           : 9         , broadcast packets    : 2

    multicast packets : 6         , CRC alignment errors : 0

    undersize packets : 0         , oversize packets     : 0

    fragments         : 0         , jabbers              : 0

    collisions        : 0         , utilization          : 0

  Sampling record 7 :

    dropevents        : 0         , octets               : 766

    packets           : 7         , broadcast packets    : 0

    multicast packets : 6         , CRC alignment errors : 0

    undersize packets : 0         , oversize packets     : 0

    fragments         : 0         , jabbers              : 0

    collisions        : 0         , utilization          : 0

  Sampling record 8 :

    dropevents        : 0         , octets               : 1154

    packets           : 13        , broadcast packets    : 1

    multicast packets : 6         , CRC alignment errors : 0

    undersize packets : 0         , oversize packets     : 0

    fragments         : 0         , jabbers              : 0

    collisions        : 0         , utilization          : 0

# Get the traffic statistics from the NMS through SNMP. (Details not shown.)

Alarm function configuration example

Network requirements

As shown in Figure 41, configure the AC to monitor the incoming traffic statistic on GigabitEthernet 1/0/1, and send RMON alarms when the following events occur:

·     The 5-second delta sample for the traffic statistic crosses the rising threshold (100).

·     The 5-second delta sample for the traffic statistic drops below the falling threshold (50).

Figure 41 Network diagram

 

Configuration procedure

# Configure the SNMP agent (the AC) with the same SNMP settings as the NMS at 1.1.1.2. This example uses SNMPv1, read community public, and write community private.

<AC> system-view

[AC] snmp-agent

[AC] snmp-agent community read public

[AC] snmp-agent community write private

[AC] snmp-agent sys-info version v1

[AC] snmp-agent trap enable

[AC] snmp-agent trap log

[AC] snmp-agent target-host trap address udp-domain 1.1.1.2 params securityname public

# Create an RMON Ethernet statistics entry for GigabitEthernet 1/0/1.

[AC] interface gigabitethernet 1/0/1

[AC-GigabitEthernet1/0/1] rmon statistics 1 owner user1

[AC-GigabitEthernet1/0/1] quit

# Create an RMON event entry and an RMON alarm entry to send SNMP notifications when the delta sample for 1.3.6.1.2.1.16.1.1.1.4.1 exceeds 100 or drops below 50.

[AC] rmon event 1 trap public owner user1

[AC] rmon alarm 1 1.3.6.1.2.1.16.1.1.1.4.1 5 delta rising-threshold 100 1 falling-threshold 50 1 owner user1

 

 

NOTE:

The string 1.3.6.1.2.1.16.1.1.1.4.1 is the object instance for GigabitEthernet 1/0/1. The digits before the last digit (1.3.6.1.2.1.16.1.1.1.4) represent the object for total incoming traffic statistics. The last digit (1) is the RMON Ethernet statistics entry index for GigabitEthernet 1/0/1.

 

# Display the RMON alarm entry.

<AC> display rmon alarm 1

AlarmEntry 1 owned by user1 is VALID.

  Sample type          : delta

  Sampled variable     : 1.3.6.1.2.1.16.1.1.1.4.1<etherStatsOctets.1>

  Sampling interval (in seconds)    : 5

  Rising threshold      : 100(associated with event 1)

  Falling threshold     : 50(associated with event 1)

  Alarm sent upon entry startup  : risingOrFallingAlarm

  Latest value          : 0

# Display statistics for GigabitEthernet 1/0/1.

<AC> display rmon statistics gigabitethernet 1/0/1

EtherStatsEntry 1 owned by user1 is VALID.

  Interface : GigabitEthernet1/0/1<ifIndex.3>

  etherStatsOctets         : 57329     , etherStatsPkts          : 455

  etherStatsBroadcastPkts  : 53        , etherStatsMulticastPkts : 353

  etherStatsUndersizePkts  : 0         , etherStatsOversizePkts  : 0

  etherStatsFragments      : 0         , etherStatsJabbers       : 0

  etherStatsCRCAlignErrors : 0         , etherStatsCollisions    : 0

  etherStatsDropEvents (insufficient resources): 0

  Incoming packets by size :

  64     : 7         ,  65-127  : 413       ,  128-255  : 35

  256-511: 0         ,  512-1023: 0         ,  1024-1518: 0

# Query alarm events on the NMS. (Details not shown.)

On the AC, alarm event messages are displayed when events occur. The following is a sample alarm event message:

[AC] % Apr  6 09:23:53:357 2013 sysname SNMP/6/SNMP_NOTIFY: Notification fallingA

larm(1.3.6.1.2.1.16.0.2) with alarmIndex(1.3.6.1.2.1.16.3.1.1.1.1)=1;alarmVariab

le(1.3.6.1.2.1.16.3.1.1.3.1)=1.3.6.1.2.1.16.1.1.1.4.1;alarmSampleType(1.3.6.1.2.

1.16.3.1.1.4.1)=2;alarmValue(1.3.6.1.2.1.16.3.1.1.5.1)=0;alarmFallingThreshold(1

.3.6.1.2.1.16.3.1.1.8.1)=50.


Configuring NETCONF

Overview

Network Configuration Protocol (NETCONF) is an XML-based network management protocol with filtering capabilities. It provides programmable mechanisms to manage and configure network devices. Through NETCONF, you can configure device parameters, retrieve parameter values, and get statistics information.

In NETCONF messages, each data item is contained in a fixed element. This enables different devices of the same vendor to provide the same access method and the same result presentation method. For the devices of different vendors, XML mapping in NETCONF messages can achieve the same effect. For a network environment containing different devices regardless of vendors, you can develop a NETCONF-based NMS system to configure and manage devices in a simple and effective way.

NETCONF structure

NETCONF has four layers: content layer, operations layer, RPC layer, and transport protocol layer.

Table 9 NETCONF layers and XML layers

NETCONF layer

XML layer

Description

Content

Configuration data, status data, and statistics information

The content layer contains a set of managed objects, which can be configuration data, status data, and statistics information. For information about the operable data, see the NETCONF XML API reference for the device.

Operations

<get>,<get-config>,<edit-config>…

The operations layer defines a set of base operations invoked as RPC methods with XML-encoded parameters. NETCONF base operations include data retrieval operations, configuration operations, lock operations, and session operations. For the device supported operations, see "Appendix A Supported NETCONF operations."

RPC

<rpc>,<rpc-reply>

The RPC layer provides a simple, transport-independent framing mechanism for encoding RPCs. The <rpc> and <rpc-reply> elements are used to enclose NETCONF requests and responses (data at the operations layer and the content layer).

Transport Protocol

Console/Telnet/SSH/HTTP/HTTPS/TLS

The transport protocol layer provides reliable, connection-oriented, serial data links.

The following login methods are available:

·     You can log in through Telnet, SSH, or the console port to perform NETCONF operations at the CLI.

·     You can log in through HTTP or HTTPS to perform NETCONF operations in the Web interface or perform NETCONF-over-SOAP operations.

 

NETCONF message format

NETCONF

IMPORTANT

IMPORTANT:

When configuring NETCONF in XML view, you must add the end mark (]]>]]>) at the end of an XML message. Otherwise, the device cannot identify the message. Examples in this chapter do not have this end mark. Do add the end mark in actual operations.

 

All NETCONF messages are XML-based and comply with RFC 4741. Any incoming NETCONF messages must pass XML Schema check before it can be processed. If a NETCONF message fails XML Schema check, the device sends an error message to the client.

For information about the NETCONF operations supported by the device and the operable data, see the NETCONF XML API reference for the device.

If a NETCONF message contains a half Chinese character, XML conversion fails, and the device returns a response with the character replaced with a question mark (?).

The following example shows a NETCONF message for getting all parameters of all interfaces on the device:

<?xml version="1.0" encoding="utf-8"?>

<rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <get-bulk>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/data:1.0">

        <Ifmgr>

          <Interfaces>

                 <Interface/>

          </Interfaces>

        </Ifmgr>

      </top>

    </filter>

  </get-bulk>

</rpc>

NETCONF over SOAP

All NETCONF over SOAP messages are XML-based and comply with RFC 4741. NETCONF messages are contained in the <Body> element of SOAP messages. NETCONF over SOAP messages also comply with the following rules:

·     SOAP messages must use the SOAP Envelope namespaces.

·     SOAP messages must use the SOAP Encoding namespaces.

·     SOAP messages cannot contain the following information:

?     DTD reference.

?     XML processing instructions.

The following example shows a NETCONF over SOAP message for getting all parameters of all interfaces on the device:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

  <env:Header>

    <auth:Authentication env:mustUnderstand="1" xmlns:auth="http://www.h3c.com/netconf/base:1.0">

      <auth:AuthInfo>800207F0120020C</auth:AuthInfo>

    </auth:Authentication>

  </env:Header>

  <env:Body>

    <rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

      <get-bulk>

        <filter type="subtree">

          <top xmlns="http://www.h3c.com/netconf/data:1.0">

            <Ifmgr>

              <Interfaces>

                <Interface/>

              </Interfaces>

            </Ifmgr>

          </top>

        </filter>

      </get-bulk>

    </rpc>

  </env:Body>

</env:Envelope>

How to use NETCONF

You can use NETCONF to manage and configure the device by using the methods in Table 10.

Table 10 NETCONF methods for configuring the device

Configuration tool

Login method

Remarks

CLI

·     Console port

·     SSH

·     Telnet

To implement NETCONF operations, copy valid NETCONF messages to the CLI in XML view.

This method is suitable for R&D and test purposes.

Standard Web interface for the device

·     HTTP

·     HTTPS

The system automatically converts the configuration operations on the Web interface to NETCONF messages and sends them to the device to implement NETCONF operations.

This method is the most commonly used method.

Custom Web interface

N/A

To use this method, you must enable NETCONF over SOAP.

By default, the device cannot interpret Custom Web interfaces' URLs. For the device to interpret these URLs, you must encode the NETCONF messages sent from a custom Web interface in SOAP.

 

Protocols and standards

·     RFC 3339, Date and Time on the Internet: Timestamps

·     RFC 4741, NETCONF Configuration Protocol

·     RFC 4742, Using the NETCONF Configuration Protocol over Secure SHell (SSH)

·     RFC 4743, Using NETCONF over the Simple Object Access Protocol (SOAP)

·     RFC 5277, NETCONF Event Notifications

·     RFC 5381, Experience of Implementing NETCONF over SOAP

·     RFC 5539, NETCONF over Transport Layer Security (TLS)

·     RFC 6241, Network Configuration Protocol

NETCONF configuration task list

Task at a glance

(Optional.) Configuring NETCONF over SOAP

(Optional.) Enabling NETCONF over SSH

(Optional.) Enabling NETCONF logging

(Required.) Establishing a NETCONF session

(Optional.) Subscribing to event notifications

(Optional.) Locking/unlocking the configuration

(Optional.) Performing the get/get-bulk operation

(Optional.) Performing the get-config/get-bulk-config operation

(Optional.) Performing the edit-config operation

(Optional.) Saving, rolling back, and loading the configuration

(Optional.) Filtering data

(Optional.) Performing CLI operations through NETCONF

(Optional.) Retrieving NETCONF session information

(Optional.) Terminating another NETCONF session

(Optional.) Returning to the CLI

 

Configuring NETCONF over SOAP

NETCONF over SOAP encapsulates NETCONF messages into SOAP messages and transmits the SOAP messages over HTTP or HTTPS. You can use a custom user interface to establish a NETCONF over SOAP session to the device and perform NETCONF operations.

To configure NETCONF over SOAP:

 

Step

Command

Remark

1.     Enter system view.

system-view

N/A

2.     Enable NETCONF over SOAP.

·     Enable NETCONF over SOAP over HTTP:
netconf soap http enable

·     Enable NETCONF over SOAP over HTTPS:
netconf soap https enable

By default, the NETCONF over SOAP feature is disabled.

3.     Apply an ACL to NETCONF over SOAP traffic.

·     Apply an ACL to NETCONF over SOAP over HTTP traffic:
netconf soap http acl { acl-number | name acl-name }

·     Apply an ACL to NETCONF over SOAP over HTTPS traffic:
netconf soap https acl { acl-number | name acl-name }

By default, no ACL is applied to NETCONF over SOAP traffic.

 

Enabling NETCONF over SSH

This feature allows users to use a client to perform NETCONF operations on the device through a NETCONF-over-SSH connection.

To enable NETCONF over SSH:

 

Step

Command

Remark

1.     Enter system view.

system-view

N/A

2.     Enable NETCONF over SSH.

netconf ssh server enable

By default, NETCONF over SSH is disabled.

3.     Specify a port to listen for NETCONF-over-SSH connections.

netconf ssh server port port-number

By default, port 830 listens for NETCONF-over-SSH connections.

 

Enabling NETCONF logging

This feature enables the device to generate NETCONF logs for different NETCONF operation sources and NETCONF operations.

To enable NETCONF logging:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable NETCONF logging.

netconf log source { all | { agent | soap | web } * } { { protocol-operation { all | { action | config | get | set | session | syntax | others } * } } | verbose }

By default, NETCONF logging is disabled.

 

Establishing a NETCONF session

After a NETCONF session is established, the device automatically sends its capabilities to the client. You must send the capabilities of the client to the device before you can perform any other NETCONF operations.

You can use the aaa session-limit command to set the maximum number of NETCONF sessions that the device can support. If the upper limit is reached, new NETCONF users cannot access the device. For information about this command, see Security Configuration Guide.

Setting the NETCONF session idle timeout time

If no NETCONF packets are exchanged on a NETCONF session within the NETCONF session idle timeout time, the device tears down the session.

To set the NETCONF session idle timeout time:

 

Task

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Set the NETCONF session idle timeout time.

netconf { soap | agent } idle-timeout minute

By default, the NETCONF session idle timeout time is as follows:

·     10 minutes for NETCONF over SOAP over HTTP sessions and NETCONF over SOAP over HTTPS sessions.

·     0 minutes for NETCONF over SSH sessions, NETCONF over Telnet sessions, and NETCONF over console sessions. The sessions never time out.

 

Entering XML view

Task

Command

Remarks

Enter XML view.

xml

Available in user view.

 

Exchanging capabilities

After you enter XML view, the client and the device exchange their capabilities before you can perform subsequent operations. The device automatically advertises its NETCONF capabilities to the client in a hello message as follows:

<?xml version="1.0" encoding="UTF-8"?><hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability><capability>urn:ietf:params:netconf:capability:notification:1.0</capability><capability>urn:ietf:params:netconf:capability:validate:1.0</capability><capability>urn:ietf:params:netconf:capability:interleave:1.0</capability><capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability><capability>urn:h3c:params:netconf:capability:h3c-netconf-ext:1.0</capability><capability>urn:h3c:params:netconf:capability:h3c-save-point:1.0</capability></capabilities><session-id>1</session-id></hello>]]>]]>

Where:

·     The <capabilities> parameter represents the capabilities supported by the device.

·     The <session-id> parameter represents the unique ID assigned to the current session.

After receiving the hello message from the device, copy the following message to notify the device of the capabilities (user-configurable) supported by the client:

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <capabilities>

    <capability>

     capability-set

   </capability>

 </capabilities>

</hello>

Where, capability-set represents the capabilities supported by the client. Use a pair of <capability> and </capability> tags to enclose a capability.

Subscribing to event notifications

After you subscribe to event notifications, the device sends event notifications to the NETCONF client when a subscribed event takes place on the device. The notifications include the code, group, severity, start time, and description of the events. The device supports only log subscription. For information about which event notifications you can subscribe to, see the system log messages reference for the device.

A subscription takes effect only on the current session. If the session is terminated, the subscription is automatically canceled.

You can send multiple subscription messages to subscribe to notification of multiple events.

Subscription procedure

# Copy the following message to the client to complete the subscription:

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <create-subscription  xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">

    <stream>NETCONF</stream>

      <filter>

        <event xmlns="http://www.h3c.com/netconf/event:1.0">

          <Code>code</Code>

            <Group>group</Group>

              <Severity>severity</Severity>

        </event>

      </filter>

      <startTime>start-time</startTime>

      <stopTime>stop-time</stopTime>

   </create-subscription>

</rpc>

Where:

·     The <stream> parameter represents the event stream type supported by the device. Only NETCONF is supported.

·     The <event> parameter represents an event to which you subscribe.

·     The <code> parameter represents a mnemonic symbol.

·     The <group> parameter represents the module name.

·     The <severity> parameter represents the severity level of the event.

·     The <start-time> parameter represents the start time of the subscription.

·     The <stop-time> argument represents the end time of the subscription.

After receiving the subscription request from the client, the device returns a response in the following format if the subscription is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">

    <ok/>

</rpc-reply>

If the subscription fails, the device returns an error message in the following format:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<rpc-error>

   <error-type>error-type</error-type>

   <error-tag>error-tag</error-tag>

   <error-severity>error-severity</error-severity>

   <error-message xml:lang="en">error-message</error-message>

</rpc-error>

</rpc-reply>

For more information about error messages, see RFC 4741.

Example for subscribing to event notifications

Network requirements

Configure a client to subscribe to all events with no time limitation. After the subscription is successful, all events on the device are sent to the client before the session between the device and client is terminated.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <capabilities>

    <capability>

            urn:ietf:params:netconf:base:1.0

    </capability>

  </capabilities>

</hello>

# Subscribe to all events with no time limitation.

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <create-subscription xmlns ="urn:ietf:params:xml:ns:netconf:notification:1.0">

    <stream>NETCONF</stream>

  </create-subscription>

</rpc>

Verifying the configuration

# If the client receives the following response, the subscription is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">

    <ok/>

</rpc-reply>

# If fan 1 on the device encounters problems, the device sends the following text to the client that has subscribed to all events:

<?xml version="1.0" encoding="UTF-8"?>

<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">

    <eventTime>2011-01-04T12:30:46</eventTime>

    <event xmlns="http://www.h3c.com/netconf/event:1.0">

        <Group>DEV</Group>

        <Code>FAN_DIRECTION_NOT_PREFERRED</Code>

        <Slot>6</Slot>

        <Severity>Alert</Severity>

        <context>Fan 1 airflow direction is not preferred on slot 6, please check it.</context>

    </event>

</notification>

# When another client (192.168.100.130) logs in to the device, the device sends a notification to the client that has subscribed to all events:

<?xml version="1.0" encoding="UTF-8"?>

<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">

    <eventTime>2011-01-04T12:30:52</eventTime>

    <event xmlns="http://www.h3c.com/netconf/event:1.0">

        <Group>SHELL</Group>

        <Code>SHELL_LOGIN</Code>

        <Slot>6</Slot>

        <Severity>Notification</Severity>

        <context>VTY logged in from 192.168.100.130.</context>

    </event>

</notification>

Locking/unlocking the configuration

The device supports multiple NETCONF sessions. Multiple users can simultaneously manage and monitor the device using NETCONF. During device configuration and maintenance or network troubleshooting, a user can lock the configuration to prevent other users from changing it. After that, only the user holding the lock can change the configuration, and other users can only read the configuration.

In addition, only the user holding the lock can release the lock. After the lock is released, other users can change the current configuration or lock the configuration. If the session of the user that holds the lock is terminated, the system automatically releases the lock.

Locking the configuration

# Copy the following text to the client to lock the configuration:

<?xml version="1.0" encoding="UTF-8"?>

  <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

    <lock>

      <target>

        <running/>

      </target>

    </lock>

  </rpc>

After receiving the lock request, the device returns a response in the following format if the lock operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

  <rpc-reply message-id="101"

  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

     <ok/>

</rpc-reply>

Unlocking the configuration

# Copy the following text to the client to unlock the configuration:

<?xml version="1.0" encoding="UTF-8"?>

  <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

    <unlock>

      <target>

        <running/>

      </target>

    </unlock>

  </rpc>

After receiving the unlock request, the device returns a response in the following format if the unlock operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

    <rpc-reply message-id="101"

    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

      <ok/>

</rpc-reply>

Example for locking the configuration

Network requirements

Lock the device configuration so that other users cannot change the device configuration.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

    <capabilities>

        <capability>

            urn:ietf:params:netconf:base:1.0

        </capability>

    </capabilities>

</hello>

# Lock the configuration.

<?xml version="1.0" encoding="UTF-8"?>

  <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

    <lock>

      <target>

        <running/>

      </target>

    </lock>

  </rpc>

Verifying the configuration

If the client receives the following response, the lock operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

    <rpc-reply message-id="101"

    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

      <ok/>

</rpc-reply>

If another client sends a lock request, the device returns the following response:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<rpc-error>

  <error-type>protocol</error-type>

  <error-tag>lock-denied</error-tag>

  <error-severity>error</error-severity>

  <error-message xml:lang="en">Lock failed because the NETCONF lock is held by another session.</error-message>

  <error-info>

    <session-id>1</session-id>

  </error-info>

  </rpc-error>

</rpc-reply>

The output shows that the lock operation failed because the client with session ID 1 held the lock, and only the client holding the lock can release the lock.

Performing service operations

You can use NETCONF to perform service operations on the device, such as retrieving and modifying the specified information. The basic operations include get, get-bulk, get-config, get-bulk-config, and edit-config, which are used to retrieve all data, retrieve configuration data, and edit the data of the specified module. For more information, see the NETCONF XML API reference for the device.

 

 

NOTE:

During a <get>, <get-bulk>, <get-config>, and <get-bulk-config> operation, NETCONF replaces unidentifiable characters in the retrieved data with question marks (?) before sending the data to the client.

 

Performing the get/get-bulk operation

The get operation is used to retrieve device configuration and state information that match the conditions. In some cases, this operation leads to inefficiency.

The get-bulk operation is used to retrieve a number of data entries starting from the data entry next to the one with the specified index. One data entry contains a device configuration entry and a state information entry. The data entry quantity is defined by the count attribute, and the index is specified by the index attribute. The returned output does not include the index information. If you do not specify the index attribute, the index value starts with 1 by default.

The get-bulk operation retrieves all the rest data entries starting from the data entry next to the one with the specified index if either of the following conditions occurs:

·     You do not specify the count attribute.

·     The number of matching data entries is less than the value of the count attribute.

# Copy the following text to the client to perform the get operation:

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <getoperation>

    <filter>

      <top xmlns="http://www.h3c.com/netconf/data:1.0">

          Specify the module, submodule, table name, and column name

      </top>

    </filter>

  </getoperation>

</rpc>

Where, the <getoperation> parameter can be <get> or <get-bulk>. The <filter> element is used to filter data, and it can contain module name, submodule name, table name, and column name.

·     If the module name and the submodule name are not provided, the operation retrieves the data for all modules and submodules. If a module name or a submodule name is provided, the operation retrieves the data for the specified module or submodule.

·     If the table name is not provided, the operation retrieves the data for all tables. If a table name is provided, the operation retrieves the data for the specified table.

·     If only the index column is provided, the operation retrieves the data for all columns. If the index column and other columns are provided, the operation retrieves the data for the index column and the specified columns.

The <get> and <get-bulk> messages are similar. A <get-bulk> message carries the count and index attributes. The following is a <get-bulk> message example:

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc="http://www.h3c.com/netconf/base:1.0">

  <get-bulk>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/data:1.0" xmlns:base="http://www.h3c.com/netconf/base:1.0">

        <Syslog>

          <Logs xc:count="5">

            <Log>

              <Index>10</Index>

           </Log>

             </Logs>

        </Syslog>

      </top>

    </filter>

  </get-bulk>

</rpc>

Where, the count attribute complies with the following rules:

·     The count attribute can be placed in the module node and table node. In other nodes, it cannot be resolved.

·     When the count attribute is placed in the module node, a descendant node inherits this count attribute if the descendant node does not contain the count attribute.

Verifying the configuration

After receiving the get-bulk request, the device returns a response in the following format if the operation is successful:

<?xml version="1.0"?>

<rpc-reply message-id="100"

           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <data>

     Device state and configuration data

  </data>

</rpc-reply>

Performing the get-config/get-bulk-config operation

The get-config and get-bulk-config operations are used to retrieve all non-default settings, which are configured by means of CLI, MIB, and Web. The <get-config> and <get-bulk-config> messages can contain the <filter> element for filtering data.

The <get-config> and <get-bulk-config> messages are similar. The following is a <get-config> message example:

<?xml version="1.0"?>

<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <get-config>

    <source>

      <running/>

    </source>

    <filter>

      <top xmlns="http://www.h3c.com/netconf/config:1.0">

          Specify the module name, submodule name, table name, and column name

      </top>

    </filter>

  </get-config>

</rpc>

Verifying the configuration

After receiving the get-config request, the device returns a response in the following format if the operation is successful:

<?xml version="1.0"?>

<rpc-reply message-id="100"   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <data>

    All data matching the specified filter

  </data>

</rpc-reply>

Performing the edit-config operation

The edit-config operation supports the following operation attributes: merge, create, replace, remove, delete, default-operation, error-option, test-option, and incremental. For more information about these attributes, see "Appendix A Supported NETCONF operations."

# Copy the following text to perform the <edit-config> operation:

<?xml version="1.0"?>

<rpc message-id="100"  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <edit-config>

    <target><running></running></target>

<error-option>

   Default operation when an error occurs

</error-option>

    <config>

      <top xmlns="http://www.h3c.com/netconf/config:1.0">

        Specify the module name, submodule name, table name, and column name

      </top>

    </config>

  </edit-config>

</rpc>

After receiving the edit-config request, the device returns a response in the following format if the operation is successful:

<?xml version="1.0">

<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <ok/>

</rpc-reply>

# Perform the get operation to verify that the current value of the parameter is the same as the value specified through the edit-config operation. (Details not shown.)

All-module configuration data retrieval example

Network requirements

Retrieve configuration data for all modules.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <capabilities>

    <capability>

            urn:ietf:params:netconf:base:1.0

    </capability>

  </capabilities>

</hello>

# Retrieve configuration data for all modules.

<rpc message-id="100"

     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <get-config>

    <source>

      <running/>

    </source>

  </get-config>

</rpc>

Verifying the configuration

If the client receives the following text, the get-config operation is successful:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:web="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">

    <data>

        <top xmlns="http://www.h3c.com/netconf/config:1.0">

            <Ifmgr>

                <Interfaces>

                    <Interface>

                        <IfIndex>1307</IfIndex>

                        <Shutdown>1</Shutdown>

                    </Interface>

                    <Interface>

                        <IfIndex>1308</IfIndex>

                        <Shutdown>1</Shutdown>

                    </Interface>

                    <Interface>

                        <IfIndex>1309</IfIndex>

                        <Shutdown>1</Shutdown>

                    </Interface>

                    <Interface>

                        <IfIndex>1311</IfIndex>

 

                            <VlanType>2</VlanType>

 

                    </Interface>

                    <Interface>

                        <IfIndex>1313</IfIndex>

 

                            <VlanType>2</VlanType>

 

                    </Interface>

                </Interfaces>

            </Ifmgr>

            <Syslog>

                <LogBuffer>

                    <BufferSize>120</BufferSize>

                </LogBuffer>

            </Syslog>

            <System>

                <Device>

                    <SysName>H3C</SysName>

                    <TimeZone>

                        <Zone>+11:44</Zone>

                        <ZoneName>beijing</ZoneName>

                    </TimeZone>

                </Device>

            </System>

            <Fundamentals>

                <WebUI>

                    <SessionAgingTime>98</SessionAgingTime>

                </WebUI>

            </Fundamentals>

        </top>

    </data>

</rpc-reply>

Syslog configuration data retrieval example

Network requirements

Retrieve configuration data for the Syslog module.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <capabilities>

    <capability>

            urn:ietf:params:netconf:base:1.0

    </capability>

  </capabilities>

</hello>

# Retrieve configuration data for the Syslog module.

<rpc message-id="100"

     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <get-config>

    <source>

      <running/>

    </source>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/config:1.0">

        <Syslog/>

      </top>

    </filter>

  </get-config>

</rpc>

Verifying the configuration

If the client receives the following text, the get-config operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">

    <data>

        <top xmlns="http://www.h3c.com/netconf/config:1.0">

            <Syslog>

                    <LogBuffer>

                        <BufferSize>120</BufferSize>

                    </LogBuffer>

            </Syslog>

        </top>

    </data>

</rpc-reply>

Example for retrieving a data entry for the interface table

Network requirements

Retrieve a data entry for the interface table.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <capabilities>

    <capability>urn:ietf:params:netconf:base:1.0</capability>

  </capabilities>

</hello>

# Retrieve a data entry for the interface table.

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:web="urn:ietf:params:xml:ns:netconf:base:1.0">

  <get-bulk>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/data:1.0" xmlns:web="http://www.h3c.com/netconf/base:1.0">

        <Ifmgr>

          <Interfaces web:count="1">

          </Interfaces>

        </Ifmgr>

      </top>

    </filter>

  </get-bulk>

</rpc>

Verifying the configuration

If the client receives the following text, the get-bulk operation is successful:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:web="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">

  <data>

    <top xmlns="http://www.h3c.com/netconf/data:1.0">

      <Ifmgr>

        <Interfaces>

          <Interface>

            <IfIndex>3</IfIndex>

            <Name>GigabitEthernet1/0/2</Name>

            <AbbreviatedName>GE1/0/2</AbbreviatedName>

            <PortIndex>3</PortIndex>

            <ifTypeExt>22</ifTypeExt>

            <ifType>6</ifType>

            <Description>GigabitEthernet 1/0/2 Interface</Description>

            <AdminStatus>2</AdminStatus>

            <OperStatus>2</OperStatus>

            <ConfigSpeed>0</ConfigSpeed>

            <ActualSpeed>100000</ActualSpeed>

            <ConfigDuplex>3</ConfigDuplex>

            <ActualDuplex>1</ActualDuplex>

          </Interface>

        </Interfaces>

      </Ifmgr>

    </top>

  </data>

</rpc-reply>

Example for changing the value of a parameter

Network requirements

Change the log buffer size for the Syslog module to 512.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <capabilities>

    <capability>urn:ietf:params:netconf:base:1.0</capability>

  </capabilities>

</hello>

# Change the log buffer size for the Syslog module to 512.

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:web="urn:ietf:params:xml:ns:netconf:base:1.0">

  <edit-config>

    <target>

      <running/>

    </target>

    <config>

      <top xmlns="http://www.h3c.com/netconf/config:1.0" web:operation="merge">

        <Syslog>

          <LogBuffer>

            <BufferSize>512</BufferSize>

          </LogBuffer>

        </Syslog>

      </top>

    </config>

  </edit-config>

</rpc>

Verifying the configuration

If the client receives the following text, the edit-config operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

    <ok/>

</rpc-reply>

Saving, rolling back, and loading the configuration

Use NETCONF to save, roll back, or load the configuration.

The save, rollback, and load operations only supplement NETCONF requests and they are resource intensive.

Do not perform the save, rollback, or load operation when another user is performing the operation. If multiple users simultaneously perform the save, rollback, or load operation, the configuration result returned to each user might be inconsistent with the user request.

Saving the configuration

# Copy the following text to the client to save the device configuration to the specified file:

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <save OverWrite="false">

    <file>Specify the configuration file name</file>

  </save>

</rpc>

The name of the specified configuration file must start with the storage media name and end with the .cfg extension. If the text includes the file column, you must specify the file name. The specified file will be used as the next-startup configuration file. If the text does not include the file column, the configuration is automatically saved to the default main next-startup configuration file.

The OverWrite attribute takes effect only when the name of the specified configuration file already exists. If the attribute uses the default value true, the current configuration is saved and the original file is overwritten. If the attribute value is set to false, the current configuration cannot be saved, and the system displays an error message.

After receiving the save request, the device returns a response in the following format if the save operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

    <rpc-reply message-id="101"

    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

      <ok/>

</rpc-reply>

Rolling back the configuration based on a configuration file

# Copy the following text to the client to roll back the configuration based on a configuration file:

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <rollback>

    <file>Specify the configuration file name</file>

  </rollback>

</rpc>

After receiving the rollback request, the device returns a response in the following format if the rollback operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

    <rpc-reply message-id="101"

    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

      <ok/>

</rpc-reply>

Rolling back the configuration based on a rollback point

This feature allows the device to roll back the running configuration based on a rollback point when one of the following situations occurs:

·     A NETCONF client sends a rollback request.

·     The NETCONF session idle time is longer than the rollback idle timeout time.

·     A NETCONF client is unexpectedly disconnected from the device.

To roll back the configuration based on a rollback point, perform the following tasks:

1.     Lock the system.

Multiple users might simultaneously use NETCONF to configure the device. To prevent other users from modifying the running configuration, H3C recommends that you lock the system before rolling back the configuration.

2.     Mark the beginning of a rollback operation. For more information, see "Performing the save-point/begin operation."

3.     Edit the device configuration. For more information, see "Performing the edit-config operation."

4.     Configure the rollback point. For more information, see "Performing the save-point/commit operation."

You can repeat this step to configure multiple rollback points.

5.     Roll back the configuration based on the rollback point. For more information, see "Performing the save-point/rollback operation."

The configuration can also be automatically rolled back based on the most recently configured rollback point when the NETCONF session idle time is longer than the rollback idle timeout time.

6.     End the rollback configuration. For more information, see "Performing the save-point/end operation."

7.     Release the lock.

Performing the save-point/begin operation

# Copy the following text to the client to mark the beginning of a rollback operation based on a rollback point:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

      <save-point>

        <begin>

          <confirm-timeout>100</confirm-timeout>

       </begin>

      </save-point>

</rpc>

Where, the <confirm-timeout> parameter specifies the rollback idle timeout time in the range of 1 to 65535 seconds (the default is 600 seconds). This parameter is optional.

After receiving the begin request, the device returns a response in the following format if the begin operation is successful:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <data>

    <save-point>

       <commit>

          <commit-id>1</commit-id>

       </commit>

    </save-point>

  </data>

</rpc-reply>

Performing the save-point/commit operation

The system supports a maximum of 50 rollback points. When the limit is reached, you must specify the force attribute to overwrite the earliest rollback point.

# Copy the following text to the client to configure the rollback point:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <save-point>

    <commit>

      <label>SUPPORT VLAN<label>

      <comment>vlan 1 to 100 and interfaces. Each vlan used for different custom as fllows: ……</comment>

     </commit>

  </save-point>

</rpc>

The <label> and <comment> parameters are optional.

After receiving the commit request, the device returns a response in the following format if the commit operation is successful:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <data>

    <save-point>

       <commit>

          <commit-id>2</commit-id>

       </commit>

    </save-point>

  </data>

</rpc-reply>

Performing the save-point/rollback operation

# Copy the following text to the client to roll back the configuration:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <save-point>

    <rollback>

      <commit-id/>

      <commit-index/>

      <commit-label/>

    </rollback>

  </save-point>

</rpc>

Where:

·     The <commit-id> parameter uniquely identifies a rollback point.

·     The <commit-index> parameter specifies 50 most recently configured rollback points. The value of 0 indicates the most recently configured one and 49 indicates the earliest configured one.

·     The <commit-label> parameter exclusively specifies a label for a rollback point. The label is not a must for a rollback point.

Specify one of these parameters to roll back the specified configuration. If no parameter is specified, this operation rolls back configuration based on the most recently configured rollback point.

After receiving the rollback request, the device returns a response in the following format if the rollback operation is successful:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <ok></ok>

</rpc-reply>

Performing the save-point/end operation

# Copy the following text to the client to end the rollback configuration:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <save-point>

    <end/>

  </save-point>

</rpc>

After receiving the end request, the device returns a response in the following format if the end operation is successful:

<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

   <ok/>

</rpc-reply>

Performing the save-point/get-commits operation

# Copy the following text to the client to get the rollback point configuration records:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <save-point>

    <get-commits>

      <commit-id/>

      <commit-index/>

      <commit-label/>

    </get-commits>

  </save-point>

</rpc>

Specify one of the <commit-id>, <commit-index>, and <commit-label> parameters to get the specified rollback point configuration records. If no parameter is specified, this operation gets records for all rollback point settings. The following text is a <save-point>/<get-commits> request example:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <save-point>

    <get-commits>

      <commit-label>SUPPORT VLAN</commit-label>

    </get-commits>

  </save-point>

</rpc>

After receiving the get commits request, the device returns a response in the following format if the get commits operation is successful:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

   <data>

      <save-point>

         <commit-information>

           <CommitID>2</CommitID>

           <TimeStamp>Thu Oct 30 11:30:28 1980</TimeStamp>

           <UserName>test</UserName>

           <Label>SUPPORT VLAN</Label>

         </commit-information>

    </save-point>

  </data>

</rpc-reply>

Performing the save-point/get-commit-information operation

# Copy the following text to the client to get the system configuration data corresponding to a rollback point:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <save-point>

    <get-commit-information>

       <commit-information>

         <commit-id/>

         <commit-index/>

         <commit-label/>

      </commit-information>

      <compare-information>

         <commit-id/>

         <commit-index/>

         <commit-label/>

      </compare-information

    </get-commit-information>

  </save-point>

</rpc>

Specify one of the <commit-id>, <commit-index>, and <commit-label> parameters to get the configuration data corresponding to the specified rollback point. The <compare-information> parameter is optional. If no parameter is specified, this operation gets the configuration data corresponding to the most recently configured rollback point. The following text is a <save-point>/<get-commit-information> request example:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <save-point>

    <get-commit-information>

               <commit-information>

                  <commit-label>SUPPORT VLAN</commit-label>

               </commit-information>

    </get-commit-information>

  </save-point>

</rpc>

After receiving the get-commit-information request, the device returns a response in the following format if the get-commit-information operation is successful:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

   <data>

     <save-point>

        <commit-information>

           <content>

              …

              interface vlan 1

              …

           </content>

        </commit-information>

     </save-point>

   </data>

</rpc-reply>

Loading the configuration

After you perform the load operation, the loaded settings are merged into the current configuration as follows:

·     New settings are directly loaded.

·     Settings that already exist in the current configuration are replaced by those loaded from the configuration file.

Some settings in a configuration file might conflict with the existing settings. For the settings in the file to take effect, delete the existing conflicting settings, and then load the configuration file.

# Copy the following text to the client to load a configuration file for the device:

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <load>

   <file>Specify the configuration file name</file>

  </load>

</rpc>

The name of the specified configuration file must start with the storage media name and end with the .cfg extension.

After receiving the load request, the device returns a response in the following format if the load operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

    <rpc-reply message-id="101"

    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

      <ok/>

</rpc-reply>

Example for saving the configuration

Network requirements

Save the current configuration to configuration file my_config.cfg.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <capabilities>

    <capability>

            urn:ietf:params:netconf:base:1.0

    </capability>

  </capabilities>

</hello>

# Save the configuration of the device to configuration file my_config.cfg.

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <save>

    <file>my_config.cfg</file>

  </save>

</rpc>

Verifying the configuration

If the client receives the following response, the save operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

    <rpc-reply message-id="101"

    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

      <ok/>

</rpc-reply>

Filtering data

You can define a filter to filter information when you perform a get, get-bulk, get-config, or get-bulk-config operation. Data filtering includes the following types:

·     Table-based filteringFilters table information.

·     Column-based filteringFilters information for a single column.

For table-based filtering to take effect, you must configure table-based filtering before column-based filtering.

Table-based filtering

You can specify a match criterion for the row attribute filter to implement table-based filtering, for example, IP address filtering. The namespace is http://www.h3c.com/netconf/base:1.0. For information about the support for table-based match, see NETCONF XML API documents.

# Copy the following text to the client to retrieve the longest data with VRF name vpn1, IP address 1.1.1.0, and mask length 24 from the IPv4 routing table:

<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:hp="http://www.hp.com/netconf/base:1.0">

  <get>

    <filter type="subtree">

      <top xmlns="http://www.hp.com/netconf/data:1.0">

        <Route>

         <Ipv4Routes>

           <RouteEntry hp:filter=” vrf vpn1 IP 1.1.1.0 MaskLen 24 longer”/>

         </Ipv4Routes>

        </Route>

      </top>

    </filter>

  </get>

</rpc>

Column-based filtering

Column-based filtering includes full match filtering, regular expression match filtering, and conditional match filtering. The full match filtering has the highest priority and the conditional match filtering has the lowest priority. When more than one filtering criterion is specified, the one with the highest priority takes effect.

Full match filtering

You can specify an element value in an XML message to implement full match filtering. If multiple element values are provided, the system returns the data that matches all the specified values.

# Copy the following text to the client to retrieve configuration data of all interfaces in UP state:

<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <get>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/data:1.0">

        <Ifmgr>

          <Interfaces>

            <Interface>

              <AdminStatus>2</AdminStatus>

            </Interface>

          </Interfaces>

        </Ifmgr>

      </top>

    </filter>

  </get>

</rpc>

You can also specify an attribute name that is the same as a column name of the current table at the row to implement full match filtering. The system returns only configuration data that matches this attribute name. The XML message equivalent to the above element-value-based full match filtering is as follows:

<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <get>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/data:1.0"xmlns:data="http://www.h3c.com/netconf/data:1.0">

        <Ifmgr>

          <Interfaces>

            <Interface data:AdminStatus="2"/>

          </Interfaces>

        </Ifmgr>

      </top>

    </filter>

  </get>

</rpc>

The above examples show that both element-value-based full match filtering and attribute-name-based full match filtering can retrieve the same configuration data for all UP interfaces.

Regular expression match filtering

To implement a complex data filtering with characters, you can add a regExp attribute for a specific element.

The supported data types include integer, date and time, character string, IPv4 address, IPv4 mask, IPv6 address, MAC address, OID, and time zone.

# Copy the following text to the client to retrieve the descriptions of interfaces, of which all the characters must be upper-case letters from A to Z:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:h3c="http://www.h3c.com/netconf/base:1.0">

  <get-config>

    <source>

      <running/>

    </source>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/config:1.0">

        <Ifmgr>

          <Interfaces>

            <Interface>

              <Description h3c:regExp="^[A-Z]*$"/>

            </Interface>

          </Interfaces>

        </Ifmgr>

      </top>

    </filter>

  </get-config>

</rpc>

Conditional match filtering

To implement a complex data filtering with digits and character strings, you can add a match attribute for a specific element. Table 11 lists the conditional match operators.

Table 11 Conditional match operators

Operation

Operator

Remarks

More than

match="more:value"

More than the specified value. The supported data types include date, digit, and character string.

Less than

match="less:value"

Less than the specified value. The supported data types include date, digit, and character string.

Not less than

match="notLess:value"

Not less than the specified value. The supported data types include date, digit, and character string.

Not more than

match="notMore:value"

Not more than the specified value. The supported data types include date, digit, and character string.

Equal

match="equal:value"

Equal to the specified value. The supported data types include date, digit, character string, OID, and BOOL.

Not equal

match="notEqual:value"

Not equal to the specified value. The supported data types include date, digit, character string, OID, and BOOL.

Include

match="include:string"

Includes the specified string. The supported data types include only character string.

Not include

match="exclude:string"

Excludes the specified string. The supported data types include only character string.

Start with

match="startWith:string"

Starts with the specified string. The supported data types include character string and OID.

End with

match="endWith:string"

Ends with the specified string. The supported data types include only character string.

 

# Copy the following text to the client to retrieve extension information about the entity whose CPU usage is more than 50%:

<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:h3c="http://www.h3c.com/netconf/base:1.0">

  <get>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/data:1.0">

        <Device>

          <ExtPhysicalEntities>

            <Entity>

              <CpuUsage h3c:match="more:50"></CpuUsage>

            </Entity>

          </ExtPhysicalEntities>

        </Device>

      </top>

    </filter>

  </get>

</rpc>

Example for filtering data with regular expression match

Network requirements

Retrieve all data including Ten-Gigabit in the Description column of the Interfaces table under the Ifmgr module.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <capabilities>

    <capability>

            urn:ietf:params:netconf:base:1.0

    </capability>

  </capabilities>

</hello>

# Retrieve all data including Ten-Gigabit in the Description column of the Interfaces table under the Ifmgr module.

<?xml version="1.0"?>

<rpc message-id="100"

     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:reg="http://www.h3c.com/netconf/base:1.0">

  <get>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/data:1.0">

        <Ifmgr>

          <Interfaces>

            <Interface>

              <Description  reg:regExp="Ten-Gigabit"/>

            </Interface>

          </Interfaces>

        </Ifmgr>

      </top>

    </filter>

  </get>

</rpc>

Verifying the configuration

If the client receives the following text, the operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:reg="http://www.h3c.com/netconf/base:1.0" message-id="100">

    <data>

        <top xmlns="http://www.h3c.com/netconf/data:1.0">

            <Ifmgr>

                <Interfaces>

                    <Interface>

                        <IfIndex>2681</IfIndex>

                        <Description>Ten-GigabitEthernet1/0/1 Interface</Description>

                    </Interface>

                    <Interface>

                        <IfIndex>2685</IfIndex>

                        <Description>Ten-GigabitEthernet1/0/2 Interface</Description>

                    </Interface>

                    <Interface>

                        <IfIndex>2689</IfIndex>

                        <Description>Ten-GigabitEthernet1/0/3 Interface</Description>

                    </Interface>

                 <Interface>

            </Ifmgr>

        </top>

    </data>

</rpc-reply>

Example for filtering data by conditional match

Network requirements

Retrieve data in the Name column with the ifindex value not less than 5000 in the Interfaces table under the Ifmgr module.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <capabilities>

    <capability>

            urn:ietf:params:netconf:base:1.0

    </capability>

  </capabilities>

</hello>

# Retrieve data in the Name column with the ifindex value not less than 5000 in the Interfaces table under the Ifmgr module.

<rpc message-id="100"

     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="http://www.h3c.com/netconf/base:1.0">

  <get>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/data:1.0">

        <Ifmgr>

          <Interfaces>

            <Interface>

              <IfIndex nc:match="notLess:5000"/>

              <Name/>

            </Interface>

          </Interfaces>

        </Ifmgr>

      </top>

    </filter>

  </get>

</rpc>

Verifying the configuration

If the client receives the following text, the operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="http://www.h3c.com/netconf/base:1.0" message-id="100">

    <data>

        <top xmlns="http://www.h3c.com/netconf/data:1.0">

            <Ifmgr>

                <Interfaces>

                    <Interface>

                        <IfIndex>7241</IfIndex>

                        <Name>NULL0</Name>

                    </Interface>

                    <Interface>

                        <IfIndex>7243</IfIndex>

                        <Name>Register-Tunnel0</Name>

                    </Interface>

                </Interfaces>

            </Ifmgr>

        </top>

    </data>

</rpc-reply>

Performing CLI operations through NETCONF

You can enclose command lines in XML messages to configure the device.

Configuration procedure

# Copy the following text to the client to execute the commands:

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <CLI>

    <Execution>

      Commands

    </Execution>

  </CLI>

</rpc>

The <Execution> element can contain multiple commands, with one command on one line.

After receiving the CLI operation request, the device returns a response in the following format if the CLI operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <CLI>

    <Execution>

      <![CDATA[Responses to the commands]]>

    </Execution>

  </CLI>

</rpc-reply>

CLI operation example

Configuration requirements

Send the display current-configuration command to the device.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <capabilities>

    <capability>

            urn:ietf:params:netconf:base:1.0

    </capability>

  </capabilities>

</hello>

# Copy the following text to the client to execute the display current-configuration command:

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <CLI>

    <Execution>

          display current-configuration

    </Execution>

  </CLI>

</rpc>

Verifying the configuration

If the client receives the following text, the operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <CLI>

    <Execution><![CDATA[<5600_1>display current-configuration

<Sysname>display current-configuration

#

version 7.1.064, ESS 5109P03

#

 sysname Sysname

#

 ftp server enable

 ftp update fast

 ftp timeout 2000

#

 irf mac-address persistent timer

 irf auto-update enable

 undo irf link-delay

#

 domain default enable system

#

 telnet server enable

#

vlan 1

#

vlan 1000

#

radius scheme system

 primary authentication 127.0.0.1 1645

return

   ]]>

   </Execution>

  </CLI>

</rpc-reply>

Retrieving NETCONF session information

You can use the get-sessions operation to retrieve NETCONF session information of the device.

# Copy the following message to the client to retrieve NETCONF session information from the device:

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <get-sessions/>

</rpc>

After receiving the get-sessions request, the device returns a response in the following format if the get-sessions operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <get-sessions>

    <Session>

      <SessionID>Configuration session ID</SessionID>

      <Line>Line information</Line>

      <UserName>Name of the user creating the session</UserName>

      <Since>Time when the session was created</Since>

      <LockHeld>Whether the session holds a lock</LockHeld>

    </Session>

  </get-sessions>

</rpc-reply>

For example, to get NETCONF session information:

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <capabilities>

    <capability>

            urn:ietf:params:netconf:base:1.0

    </capability>

  </capabilities>

</hello>

# Copy the following message to the client to get the current NETCONF session information on the device:

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <get-sessions/>

</rpc>

If the client receives a message as follows, the operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">

    <get-sessions>

        <Session>

            <SessionID>1</SessionID>

            <Line>vty0</Line>

            <UserName></UserName>

            <Since>2011-01-05T00:24:57</Since>

            <LockHeld>false</LockHeld>

        </Session>

    </get-sessions>

</rpc-reply>

The output shows the following information:

·     The session ID of an existing NETCONF session is 1.

·     The login user type is vty0.

·     The login time is 2011-01-05T00:24:57.

·     The user does not hold the lock of the configuration.

Terminating another NETCONF session

NETCONF allows one client to terminate the NETCONF session of another client. The client whose session is terminated returns to user view.

Configuration procedure

# Copy the following message to the client to terminate the specified NETCONF session:

<rpc message-id="101"    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <kill-session>

    <session-id>

      Specified session-ID

    </session-id>

  </kill-session>

</rpc>

After receiving the kill-session request, the device returns a response in the following format if the kill-session operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

    <rpc-reply message-id="101"

    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

      <ok/>

</rpc-reply>

Configuration example

Configuration requirement

The user whose session's ID is 1 terminates the session with session ID 2.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <capabilities>

    <capability>

            urn:ietf:params:netconf:base:1.0

    </capability>

  </capabilities>

</hello>

# Terminate the session with session ID 2.

<rpc message-id="101"    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <kill-session>

    <session-id>2</session-id>

  </kill-session>

</rpc>

Verifying the configuration

If the client receives the following text, the NETCONF session with session ID 2 has been terminated, and the client with session ID 2 has returned from XML view to user view:

<?xml version="1.0" encoding="UTF-8"?>

  <rpc-reply message-id="101"  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

    <ok/>

</rpc-reply>

Returning to the CLI

To return from XML view to the CLI, send the following close-session request:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

   <close-session/>

</rpc>

When the device receives the close-session request, it sends the following response and returns to CLI's user view:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

   <ok/>

</rpc-reply>

 


Appendix

Appendix A Supported NETCONF operations

Table 12 lists the NETCONF operations available with Comware V7.

Table 12 NETCONF operations

Operation

Description

XML example

get

Retrieves device configuration and state information.

To retrieve device configuration and state information for the Syslog module:

<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc="http://www.h3c.com/netconf/base:1.0">

  <get>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/data:1.0">

        <Syslog>

        </Syslog>

      </top>

    </filter>

  </get>

</rpc>

get-config

Retrieves the non-default configuration data. If non-default configuration data does not exist, the device returns a response with empty data.

To retrieve non-default configuration data for the interface table:

<rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc="http://www.h3c.com/netconf/base:1.0">

  <get-config>

    <source>

      <running/>

    </source>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/config:1.0">

        <Ifmgr>

          <Interfaces>

            <Interface/>

           </Interfaces>

        </Ifmgr>

      </top>

    </filter>

  </get-config>

</rpc>

get-bulk

Retrieves a number of data entries (including device configuration and state information) starting from the data entry next to the one with the specified index.

To retrieve device configuration and state information for all interface:

<rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <get-bulk>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/data:1.0">

        <Ifmgr>

          <Interfaces xc:count=" " xmlns:xc=" http://www.h3c.com/netconf/base:1.0">

           <Interface/>

          </Interfaces>

        </Ifmgr>

      </top>

    </filter>

  </get-bulk>

</rpc>

get-bulk-config

Retrieves a number of non-default configuration data entries starting from the data entry next to the one with the specified index.

To retrieve non-default configuration for all interfaces:

<rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <get-bulk-config>

    <source>

      <running/>

    </source>

    <filter type="subtree">

      <top xmlns="http://www.h3c.com/netconf/config:1.0">

        <Ifmgr>

        </Ifmgr>

      </top>

    </filter>

  </get-bulk-config>

</rpc>

edit-config:

incremental

Adds configuration data to a column without affecting the original data.

The incremental attribute applies to a list column such as the vlan permitlist column.

You can use the incremental attribute for edit-config operations except for the replace operation.

Support for the incremental attribute varies by module. For more information, see NETCONF XML API documents.

To add VLANs 1 through 10 to an untagged VLAN list that has untagged VLANs 12 through 15:

<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"

h3c:xmlns=” http://www.h3c.com/netconf/base:1.0”>

  <edit-config>

    <target>

      <running/>

    </target>

    <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">

      <top xmlns="http://www.h3c.com/netconf/config:1.0">

        <VLAN xc:operation="merge">

          <HybridInterfaces>

            <Interface>

              <IfIndex>262</IfIndex>

              <UntaggedVlanList  h3c: incremental=”true”>1-10</UntaggedVlanList>

               </Interface>

          </HybridInterfaces>

        </VLAN>

      </top>

    </config>

  </edit-config>

</rpc>

edit-config: merge

Changes the running configuration.

To use the merge attribute in the edit-config operation, you must specify the operation target (on a specified level):

·     If the specified target exists, the operation directly changes the configuration for the target.

·     If the specified target does not exist, the operation creates and configures the target.

·     If the specified target does not exist and it cannot be created, an error message is returned.

To change the buffer size to 120:

<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"  xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">

  <edit-config>

    <target>

      <running/>

    </target>

    <config>

      <top xmlns="http://www.h3c.com/netconf/config:1.0">

        <Syslog xmlns="http://www.h3c.com/netconf/config:1.0" xc:operation="merge">

           <LogBuffer>

            <BufferSize>120</BufferSize>

          </LogBuffer>

        </Syslog>

      </top>

    </config>

  </edit-config>

</rpc>

edit-config: create

Creates a specified target. To use the create attribute in the edit-config operation, you must specify the operation target.

·     If the table supports target creation and the specified target does not exist, the operation creates and then configures the target.

·     If the specified target exists, a data-exist error message is returned.

The XML data format is the same as the edit-config message with the merge attribute. Change the operation attribute from merge to create.

edit-config: replace

Replaces the specified target.

·     If the specified target exists, the operation replaces the configuration of the target with the configuration carried in the message.

·     If the specified target does not exist but is allowed to be created, create the target and then apply the configuration of the target.

·     If the specified target does not exist and is not allowed to be created, the operation is not conducted and an invalid-value error message is returned.

The syntax is the same as the edit-config message with the merge attribute. Change the operation attribute from merge to replace.

edit-config: remove

Removes the specified configuration.

·     If the specified target has only the table index, the operation removes all configuration of the specified target, and the target itself.

·     If the specified target has the table index and configuration data, the operation removes the specified configuration data of this target.

·     If the specified target does not exist, or the XML message does not specify any targets, a success message is returned.

The syntax is the same as the edit-config message with the merge attribute. Change the operation attribute from merge to remove.

edit-config: delete

Deletes the specified configuration.

·     If the specified target has only the table index, the operation removes all configuration of the specified target, and the target itself.

·     If the specified target has the table index and configuration data, the operation removes the specified configuration data of this target.

·     If the specified target does not exist, an error message is returned, showing that the target does not exist.

The syntax is the same as the edit-config message with the merge attribute. Change the operation attribute from merge to delete.

edit-config: default-operation

Modifies the current configuration of the device using the default operation method.

If you do not specify an operation attribute for an edit-config message, NETCONF uses one of the following default operation attributes: merge, create, delete, and replace. Your setting of the value for the <default-operation> element takes effect only once. If you do not specify an operation attribute and the default operation method for an <edit-config> message, merge is always applied.

·     merge—The default value for the <default-operation> element.

·     replaceValue used when the operation attribute is not specified and the default operation method is specified as replace.

·     noneValue used when the operation attribute is not specified and the default operation method is specified as none. If this value is specified, the edit-config operation is used only for schema verification rather than issuing a configuration. If the schema verification is passed, a successful message is returned. Otherwise, an error message is returned.

To issue an empty operation for schema verification purposes:

<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <edit-config>

    <target>

      <running/>

    </target>

    <default-operation>none</default-operation>

    <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">

      <top xmlns="http://www.h3c.com/netconf/config:1.0">

        <Ifmgr>

          <Interfaces>

            <Interface>

              <IfIndex>262</IfIndex>

              <Description>222222</Description>

            </Interface>

          </Interfaces>

        </Ifmgr>

      </top>

    </config>

  </edit-config>

</rpc>

edit-config: error-option

Determines the action to take in case of a configuration error.

The error-option element has one of the following values:

·     stop-on-error—Stops the operation on error and returns an error message. This is the default error-option value.

·     continue-on-error—Continues the operation on error and returns an error message.

·     rollback-on-error—Rolls back the configuration.

To issue the configuration for two interfaces with the error-option element value as continue-on-error:

<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <edit-config>

    <target>

      <running/>

    </target>   <error-option>continue-on-error</error-option>

    <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">

      <top xmlns="http://www.h3c.com/netconf/config:1.0">

        <Ifmgr xc:operation="merge">

          <Interfaces>

            <Interface>

              <IfIndex>262</IfIndex>

              <Description>222</Description>

                <ConfigSpeed>1000000</ConfigSpeed>

                <ConfigDuplex>1</ConfigDuplex>

            </Interface>

            <Interface>

              <IfIndex>263</IfIndex>

              <Description>333</Description>

                <ConfigSpeed>1000000</ConfigSpeed>

                <ConfigDuplex>1</ConfigDuplex>

            </Interface>

          </Interfaces>

        </Ifmgr>

      </top>

    </config>

  </edit-config>

</rpc>

edit-config: test-option

Determines whether to issue a configuration item in the edit-configure operation. The test-option element has one of the following values:

·     test-then-set—Performs a validation test before attempting to set. If the validation test fails, the edit-config operation is not performed. This is the default test-option value.

·     set—Directly performs the set operation without the validation test.

·     test-only—Performs only a validation test without attempting to set. If the validation test succeeds, a successful message is returned. Otherwise, an error message is returned.

To issue the configuration for an interface for test purposes:

<rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <edit-config>

    <target>

      <running/>

    </target>

    <test-option>test-only</test-option>

    <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">

      <top xmlns="http://www.h3c.com/netconf/config:1.0">

        <Ifmgr xc:operation="merge">

          <Interfaces>

            <Interface>

              <IfIndex>262</IfIndex>

              <Description>222</Description>

                <ConfigSpeed>2</ConfigSpeed>

                <ConfigDuplex>1</ConfigDuplex>

               </Interface>

          </Interfaces>

        </Ifmgr>

      </top>

    </config>

  </edit-config>

</rpc>

action

Issues actions that are not for configuring data, for example, reset action.

To clear statistics information for all interfaces:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <action>

    <top xmlns="http://www.h3c.com/netconf/action:1.0">

      <Ifmgr>

            <ClearAllIfStatistics>

                <Clear>

                </Clear>

        </ClearAllIfStatistics>

      </Ifmgr>

    </top>

  </action>

</rpc>

lock

Locks the configuration data made through NETCONF sessions. The configuration data can be changed by the edit-config operation. Other configuration data are not limited by the lock operation.

This lock operation does not lock configuration data made through other protocols, for example, SNMP.

To lock the configuration:

<rpc message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

 <lock>

    <target>

        <running/>

    </target>

</lock>

</rpc>

unlock

Unlocks the configuration, so NETCONF sessions can change device configuration.

When a NETCONF session is terminated, the related locked configuration is also unlocked.

To unlock the configuration:

<rpc message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<unlock>

    <target>

        <running/>

    </target>

</unlock>

</rpc>

get-sessions

Retrieves information about all NETCONF sessions in the system.

To retrieve information about all NETCONF sessions in the system:

<rpc message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<get-sessions/>

</rpc>

close-session

Terminates the NETCONF session for the current user, to unlock the configuration and release the resources (for example, memory) of this session. This operation logs the current user off the XML view.

To terminate the NETCONF session for the current user:

<rpc message-id="101"          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<close-session/>

</rpc>

kill-session

Terminates the NETCONF session for another user. This operation cannot terminate the NETCONF session for the current user.

To terminate the NETCONF session with session-id 1:

<rpc message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <kill-session>

    <session-id>1</session-id>

  </kill-session>

</rpc>

CLI

Executes CLI operations. A request message encloses commands in the <CLI> element, and a response message encloses the command output in the <CLI> element.

NETCONF supports the following views:

·     Execution—User view.

·     Configuration—System view.

To execute a command in other views, specify the command for entering the specified view, and then the desired command.

To execute the display this command in system view:

<rpc message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <CLI>

    <Configuration>display this</Configuration>

  </CLI>

</rpc>

save

Saves the running configuration. You can use the <file> element to specify a file for saving the configuration. If the text does not include the file column, the running configuration is automatically saved to the main next-startup configuration file.

The OverWrite attribute determines whether the current configuration overwrites the original configuration file when the specified file already exists.

To save the running configuration to the file test.cfg:

<rpc message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <save OverWrite="false">

    <file>test.cfg</file>

  </save>

</rpc>

load

Loads the configuration. After the device finishes the load operation, the configuration in the specified file is merged into the current configuration of the device.

To merge the configuration in the file a1.cfg to the current configuration of the device:

<rpc message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <load>

    <file>a1.cfg</file>

  </load>

</rpc>

rollback

Rolls back the configuration. To do so, you must specify the configuration file in the <file> element. After the device finishes the rollback operation, the current device configuration is totally replaced with the configuration in the specified configuration file.

To roll back the current configuration to the configuration in the file 1A.cfg:

<rpc message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<rollback>

    <file>1A.cfg</file>

</rollback>

</rpc>

 


Configuring EAA

Overview

Embedded Automation Architecture (EAA) is a monitoring framework that enables you to self-define monitored events and actions to take in response to an event. It allows you to create monitor policies by using the CLI or Tcl scripts.

EAA framework

EAA framework includes a set of event sources, a set of event monitors, a real-time event manager (RTM), and a set of user-defined monitor policies, as shown in Figure 42.

Figure 42 EAA framework

 

Event sources

Event sources are software or hardware modules that create events (see Figure 42).

For example, the CLI module creates an event when you enter a command. The Syslog module (the information center) creates an event when it receives a log message.

Event monitors

EAA creates one event monitor to monitor the system for the event specified in each monitor policy. An event monitor notifies the RTM to run the monitor policy when the monitored event occurs.

RTM

RTM manages the creation, state machine, and execution of monitor policies.

EAA monitor policies

A monitor policy specifies the event to monitor and actions to take when the event occurs.

You can configure EAA monitor policies by using the CLI or Tcl.

A monitor policy contains the following elements:

·     One event.

·     A minimum of one action.

·     A minimum of one user role.

·     One running time setting.

For more information about these elements, see "Elements in a monitor policy."

Elements in a monitor policy

Event

Table 13 shows types of events that EAA can monitor.

Table 13 Monitored events

Event type

Description

CLI

CLI event occurs in response to monitored operations performed at the CLI. For example, a command is entered, a question mark (?) is entered, or the Tab key is pressed to complete a command.

Syslog

Syslog event occurs when the information center receives the monitored log within a specific period.

NOTE:

The log that is generated by the EAA RTM does not trigger the monitor policy to run.

Process

Process event occurs in response to a state change of the monitored process (such as an exception, shutdown, start, or restart). Both manual and automatic state changes can cause the event to occur.

Interface

Each interface event is associated with two user-defined thresholds: start and restart.

An interface event occurs when the monitored interface traffic statistic crosses the start threshold in the following situations:

·     The statistic crosses the start threshold for the first time.

·     The statistic crosses the start threshold each time after it crosses the restart threshold.

SNMP

Each SNMP event is associated with two user-defined thresholds: start and restart.

SNMP event occurs when the monitored MIB variable's value crosses the start threshold in the following situations:

·     The monitored variable's value crosses the start threshold for the first time.

·     The monitored variable's value crosses the start threshold each time after it crosses the restart threshold.

SNMP-Notification

SNMP-Notification event occurs when the monitored MIB variable's value in an SNMP notification matches the specified condition. For example, the broadcast traffic rate on an Ethernet interface reaches or exceeds 30%.

Track

Track event occurs when the state of the track entry changes from Positive to Negative or from Negative to Positive. If you specify multiple track entries for a policy, EAA triggers the policy only when the state of all the track entries changes from Positive (Negative) to Negative (Positive).

If you set a suppress time, the timer starts when the policy is triggered. The system does not process the messages that report the track entry state change from  Positive (Negative) to Negative (Positive) until the timer times out.

 

Action

You can create a series of order-dependent actions to take in response to the event specified in the monitor policy.

The following are available actions:

·     Executing a command.

·     Sending a log.

·     Enabling an active/standby switchover.

·     Executing a reboot without saving the running configuration.

User role

For EAA to execute an action in a monitor policy, you must assign the policy the user role that has access to the action-specific commands and resources. If EAA lacks access to an action-specific command or resource, EAA does not perform the action and all the subsequent actions.

For example, a monitor policy has four actions numbered from 1 to 4. The policy has user roles that are required for performing actions 1, 3, and 4. However, it does not have the user role required for performing action 2. When the policy is triggered, EAA executes only action 1.

For more information about user roles, see RBAC in Fundamentals Configuration Guide.

Runtime

Policy runtime limits the amount of time that the monitor policy can run from the time it is triggered. This setting prevents system resources from being occupied by incorrectly defined policies.

EAA environment variables

EAA environment variables decouple the configuration of action arguments from the monitor policy so you can modify a policy easily.

An EAA environment variable is defined as a <variable_name variable_value> pair and can be used in different policies. When you define an action, you can enter a variable name with a leading dollar sign ($variable_name). EAA will replace the variable name with the variable value when it performs the action.

To change the value for an action argument, modify the value specified in the variable pair instead of editing each affected monitor policy.

EAA environment variables include system-defined variables and user-defined variables.

System-defined variables

System-defined variables are provided by default, and they cannot be created, deleted, or modified by users. System-defined variable names start with an underscore (_) sign. The variable values are set automatically depending on the event setting in the policy that uses the variables.

System-defined variables include the following types:

·     Public variable—Available for any events.

·     Event-specific variable—Available only for a type of event.

Table 14 shows all system-defined variables.

Table 14 System-defined EAA environment variables by event type

Variable name

Description

Any event:

 

_event_id

Event ID.

_event_type

Event type.

_event_type_string

Event type description.

_event_time

Time when the event occurs.

_event_severity

Severity level of an event.

CLI:

 

_cmd

Commands that are matched.

Syslog:

 

_syslog_pattern

Log message content.

Interface:

 

_ifname

Interface name.

SNMP:

 

_oid

OID of the MIB variable where an SNMP operation is performed.

_oid_value

Value of the MIB variable.

SNMP-Notification:

 

_oid

OID that is included in the SNMP notification.

Process:

 

_process_name

Process name.

 

User-defined variables

You can use user-defined variables for all types of events.

User-defined variable names can contain digits, characters, and the underscore sign (_), except that the underscore sign cannot be the leading character.

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

Configuring a user-defined EAA environment variable

Configure a user-defined EAA environment variable before you use it in an action.

To configure a user-defined EAA environment variable:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure a user-defined EAA environment variable.

rtm environment var-name var-value

By default, no user-defined environment variables are configured. The system provides the system-defined variables in Table 14.

 

Configuring a monitor policy

You can configure a monitor policy by using the CLI or Tcl.

Configuration restrictions and guidelines

When you configure monitor policies, follow these restrictions and guidelines:

·     Make sure the actions in different policies do not conflict. Policy execution result will be unpredictable if policies that conflict in actions are running concurrently.

·     You can assign the same policy name to a CLI-defined policy and a Tcl-defined policy. However, you cannot assign the same name to policies that are the same type.

·     The system executes the actions in a policy in ascending order of action IDs. When you add actions to a policy, you must make sure the execution order is correct.

Configuring a monitor policy from the CLI

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter CLI-defined policy view.

rtm cli-policy policy-name

If the policy does not exist, this command creates the policy first.

3.     Configure an event in the policy.

·     Configure a CLI event:
event cli { async [ skip ] | sync } mode { execute | help | tab } pattern regular-exp

·     Configure an interface event:
event interface interface-type interface-number monitor-obj monitor-obj start-op start-op start-val start-val restart-op restart-op restart-val restart-val [ interval interval ]

·     Configure a process event:
event process { exception | restart | shutdown | start } [ name process-name [ instance instance-id ] ] [ slot slot-number ]

·     Configure an SNMP event:
event snmp oid oid monitor-obj { get | next } start-op start-op start-val start-val restart-op restart-op restart-val restart-val [ interval interval ]

·     Configure an SNMP-Notification event:
event snmp-notification oid oid oid-val oid-val op op [ drop ]

·     Configure a Syslog event:
event syslog priority level msg msg occurs times period period

·     Configure a track event:
event track track-list state { negative | positive } [ suppress-time suppress-time ]

By default, a monitor policy does not contain an event.

You can configure only one event in a monitor policy. If the monitor policy already contains an event, the new event overrides the old event.

4.     Configure the actions to take when the event occurs.

·     Configure the action to execute a command:
action number cli command-line

·     Configure a reboot action:
action number reboot
[ slot slot-number ]

·     Configure a logging action:
action syslog priority level facility local-number msg msg-body

·     Configure an active/standby switchover action:
action number switchover

By default, a monitor policy does not contain any actions.

Repeat this step to add a maximum of 232 actions to the policy.

When you define an action, you may choose to specify a value or specify a variable name in $variable_name format for an argument.

5.     (Optional.) Assign a user role to the policy.

user-role role-name

By default, a monitor policy contains user roles that its creator had at the time of policy creation.

A monitor policy supports a maximum of 64 valid user roles. User roles added after this limit is reached do not take effect.

An EAA policy cannot have both the security-audit user role and any other user roles. Any previously assigned user roles are automatically removed when you assign the security-audit user role to the policy. The previously assigned security-audit user role is automatically removed when you assign any other user roles to the policy.

6.     (Optional.) Configure the policy runtime.

running-time time

The default runtime is 20 seconds.

7.     Enable the policy.

commit

By default, CLI-defined policies are not enabled.

A CLI-defined policy can take effect only after you perform this step.

 

Configuring a monitor policy by using Tcl

Step

Command

Remarks

1.     Edit a Tcl script file (see Table 15).

N/A

The supported Tcl version is 8.5.8.

2.     Download the file to the device by using FTP or TFTP.

N/A

For more information about using FTP and TFTP, see Fundamentals Configuration Guide.

3.     Enter system view.

system-view

N/A

4.     Create a Tcl-defined policy and bind it to the Tcl script file.

rtm tcl-policy policy-name tcl-filename

By default, the system does not have Tcl policies.

This step enables the Tcl-defined policy.

To revise the Tcl script of a policy, you must suspend all monitor policies first, and then resume the policies after you finish revising the script. The system cannot execute a Tcl-defined policy if you edit its Tcl script without first suspending these policies.

 

Write a Tcl script in two lines for a monitor policy, as shown in Table 15.

Table 15 Tcl script requirements

Line

Content

Requirements

Line 1

Event, user roles, and policy runtime

This line must use the following format:

::comware::rtm::event_register eventname arg1 arg2 arg3user-role rolename1 | [ user-role rolename2 | [ ] ][ running-time running-time ]

The arg1 arg2 arg3 … arguments represent event matching rules. If an argument value contains spaces, use double quotation marks ("") to enclose the value. For example, "a b c."

Line 2

Actions

When you define an action, you may choose to specify a value or specify a variable name in $variable_name format for an argument.

The following actions are available:

·     Standard Tcl commands.

·     EAA-specific Tcl commands.

·     Commands supported by the device.

 

Suspending monitor policies

This task suspends all CLI-defined and Tcl-defined monitor policies except for the policies that are running.

To suspend monitor policies:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Suspend monitor policies.

rtm scheduler suspend

To resume monitor polices, use the undo rtm scheduler suspend command.

 

Displaying and maintaining EAA settings

Execute display commands except for the display this command in any view.

 

Task

Command

Display user-defined EAA environment variables.

display rtm environment [ var-name ]

Display EAA monitor policies.

display rtm policy { active | registered [ verbose ] } [ policy-name ]

Display the running configuration of all CLI-defined monitor policies.

display current-configuration

Display the running configuration of a CLI-defined monitor policy in CLI-defined monitor policy view.

display this

 

EAA configuration examples

CLI-defined policy configuration example

Network requirements

Configure a policy from the CLI to monitor the event that occurs when a question mark (?) is entered at the command line that contains letters and digits.

When the event occurs, the system executes the command and sends the log message "hello world" to the information center and create VLAN 2.

Configuration procedure

# Create CLI-defined policy test and enter its view.

<AC> system-view

[AC] rtm cli-policy test

# Add a CLI event that occurs when a question mark (?) is entered at any command line that contains letters and digits.

[AC-rtm-test] event cli async mode help pattern [a-zA-Z0-9]

# Add an action that sends the message "hello world" with a priority of 4 from the logging facility local3 when the event occurs.

[AC-rtm-test] action 0 syslog priority 4 facility local3 msg “hello world”

# Add an action that enters system view when the event occurs.

[AC-rtm-test] action 2 cli system-view

# Add an action that creates VLAN 2 when the event occurs.

[AC-rtm-test] action 3 cli vlan 2

# Set the policy runtime to 2000 seconds. The system stops executing the policy and displays an execution failure message if it fails to complete policy execution within 2000 seconds.

[AC-rtm-test] running-time 2000

# Specify the network-admin user role for executing the policy.

[AC-rtm-test] user-role network-admin

# Enable the policy.

[AC-rtm-test] commit

Verifying the configuration

# Display information about the policy.

[AC-rtm-test] display rtm policy registered

Total number: 1

Type  Event      TimeRegistered       PolicyName

CLI   CLI        Aug 29 14:56:50 2013 test

# Enable the information center to output log messages to the current monitoring terminal.

[AC-rtm-test] return

<AC> terminal monitor

# Enter a question mark (?) at a command line that contains a letter d. Verify that the system displays the "hello world" message and a policy successfully executed message on the terminal screen.

<AC> d?

  debugging

  delete

  diagnostic-logfile

  dir

  display

 

<AC>d%May  7 02:10:03:218 2013 AC RTM/4/RTM_ACTION: "hello world"

%May  7 02:10:04:176 2013 AC RTM/6/RTM_POLICY: CLI policy test is running successfully.

CLI-defined policy with EAA environment variables configuration example

Network requirements

Define an environment variable to match the IP address 1.1.1.1.

Configure a policy from the CLI to monitor the event that occurs when a command line that contains loopback0 is executed. In the policy, use the environment variable for IP address assignment.

When the event occurs, the system performs the following tasks:

·     Creates the Loopback 0 interface.

·     Assigns 1.1.1.1/24 to the interface.

·     Sends the matching command line to the information center.

Configuration procedure

# Configure an EAA environment variable for IP address assignment. The variable name is loopback0IP, and the variable value is 1.1.1.1.

<AC> system-view

[AC] rtm environment loopback0IP 1.1.1.1

# Create the CLI-defined policy test and enter its view.

[AC] rtm cli-policy test

# Add a CLI event that occurs when a command line that contains loopback0 is executed.

[AC-rtm-test] event cli async mode execute pattern loopback0

# Add an action that enters system view when the event occurs.

[AC-rtm-test] action 0 cli system-view

# Add an action that creates the interface Loopback 0 and enters loopback interface view.

[AC-rtm-test] action 1 cli interface loopback 0

# Add an action that assigns the IP address 1.1.1.1 to Loopback 0. The loopback0IP variable is used in the action for IP address assignment.

[AC-rtm-test] action 2 cli ip address $loopback0IP 24

# Add an action that sends the matching loopback0 command with a priority of 0 from the logging facility local7 when the event occurs.

[AC-rtm-test] action 3 syslog priority 0 facility local7 msg $_cmd

# Specify the network-admin user role for executing the policy.

[AC-rtm-test] user-role network-admin

# Enable the policy.

[AC-rtm-test] commit

[AC-rtm-test] return

<AC>

Verifying the configuration

# Enable the information center to output log messages to the current monitoring terminal.

<AC> terminal monitor

# Execute the loopback0 command. Verify that the system displays the loopback0 message and a policy successfully executed message on the terminal screen.

<AC> loopback0

<AC>

%Jan  3 09:46:10:592 2014 AC RTM/0/RTM_ACTION: loopback0

%Jan  3 09:46:10:613 2014 AC RTM/6/RTM_POLICY: CLI policy test is running successfully.

# Verify that Loopback 0 has been created and assigned the IP address 1.1.1.1.

<AC> display interface loopback brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface            Link Protocol Primary IP         Description

Loop0                UP   UP(s)    1.1.1.1

 

<AC>

Tcl-defined policy configuration example

Network requirements

As shown in Figure 43, use Tcl to create a monitor policy on the Device. This policy must meet the following requirements:

·     EAA sends the log message "rtm_tcl_test is running" when a command that contains the display this string is entered.

·     The system executes the command only after it executes the policy successfully.

Figure 43 Network diagram

Configuration procedure

# Edit a Tcl script file (rtm_tcl_test.tcl, in this example) for EAA to send the message "rtm_tcl_test is running" when a command that contains the display this string is executed.

::comware::rtm::event_register cli sync mode execute pattern display this user-role network-admin

::comware::rtm::action syslog priority 1 facility local4 msg rtm_tcl_test is running

# Download the Tcl script file from the TFTP server at 1.2.1.1.

<AC> tftp 1.2.1.1 get rtm_tcl_test.tcl

# Create Tcl-defined policy test and bind it to the Tcl script file.

<AC> system-view

[AC] rtm tcl-policy test rtm_tcl_test.tcl

[AC] quit

Verifying the configuration

# Display information about the policy.

<AC> display rtm policy registered

Total number: 1

Type  Event      TimeRegistered       PolicyName

TCL   CLI        Aug 29 14:54:50 2013 test

# Enable the information center to output log messages to the current monitoring terminal.

<AC> terminal monitor

# Execute the display this command. Verify that the system displays the rtm_tcl_test is running message and a message that the policy is being successfully executed.

<AC> display this

#

return

<AC>%Jun  4 15:02:30:354 2013 AC RTM/1/RTM_ACTION: rtm_tcl_test is running

%Jun  4 15:02:30:382 2013 AC RTM/6/RTM_POLICY: TCL policy test is running successfully.


Monitoring and maintaining processes

Overview

H3C Comware V7 is a full-featured, modular, and scalable network operating system based on the Linux kernel. Comware V7 software features run the following types of independent processes:

·     User process—Runs in user space. Most Comware V7 software features run user processes. Each process runs in an independent space so the failure of a process does not affect other processes. The system automatically monitors user processes. Comware V7 supports preemptive multithreading. A process can run multiple threads to support multiple activities. Whether a process supports multithreading depends on the software implementation.

·     Kernel thread—Runs in kernel space. A kernel thread executes kernel code. It has a higher security level than a user process. If a kernel thread fails, the system breaks down. You can monitor the running status of kernel threads.

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

Displaying and maintaining processes

Commands described in this section apply to both user processes and kernel threads. You can execute these commands in any view.

The system identifies a process that consumes excessive memory or CPU resources as an anomaly source.

To display and maintain processes:

 

Task

Command

Display memory usage.

display memory [ slot slot-number [ cpu cpu-number ] ]

Display process state information.

display process [ all | job job-id | name process-name ] [ slot slot-number [ cpu cpu-number ] ]

Display CPU usage for all processes.

display process cpu [ slot slot-number [ cpu cpu-number ] ]

Monitor process running state.

monitor process [ dumbtty ] [ iteration number ] [ slot slot-number [ cpu cpu-number ] ]

Monitor thread running state.

monitor thread [ dumbtty ] [ iteration number ] [ slot slot-number [ cpu cpu-number ] ]

 

For more information about the display memory [ slot slot-number ] command, see Fundamentals Command Reference.

Displaying and maintaining user processes

Execute display commands in any view and other commands in user view.

 

Task

Command

Display log information for all user processes.

display process log [ slot slot-number [ cpu cpu-number ] ]

Display memory usage for all user processes.

display process memory [ slot slot-number [ cpu cpu-number ] ]

Display heap memory usage for a user process.

display process memory heap job job-id [ verbose ] [ slot slot-number [ cpu cpu-number ] ]

Display the addresses of memory blocks with a specified size used by a user process.

display process memory heap job job-id size memory-size [ offset offset-size ] [ slot slot-number [ cpu cpu-number ] ]

Display memory content starting from a specified memory block for a user process.

display process memory heap job job-id address starting-address length memory-length [ slot slot-number [ cpu cpu-number ] ]

Display context information for process exceptions.

display exception context [ count value ] [ slot slot-number [ cpu cpu-number ] ]

Display the core file directory.

display exception filepath [ slot slot-number [ cpu cpu-number ] ]

Enable or disable a process to generate core files for exceptions and set the maximum number of core files (which defaults to 1).

process core { maxcore value | off } { job job-id | name process-name } [ slot slot-number [ cpu cpu-number ] ]

Specify the directory for saving core files (By default, the core files are saved in the root directory of the storage media).

exception filepath directory

Clear context information for process exceptions.

reset exception context [ slot slot-number [ cpu cpu-number ] ]

 

Monitoring kernel threads

Tasks in this section help you quickly identify thread deadloop and starvation problems and their causes.

Configuring kernel thread deadloop detection

CAUTION

CAUTION:

H3C recommends the default settings. Inappropriate configuration of kernel thread deadloop detection can cause service problems or system breakdown. Make sure you understand the impact of this configuration on your network before you configure kernel thread deadloop detection.

 

Kernel threads share resources. If a kernel thread monopolizes the CPU, other threads cannot run, resulting in a deadloop.

This feature enables the device to detect deadloops. If a thread occupies the CPU for a specific interval, the device considers that a deadloop has occurred. It generates a deadloop message and reboots to remove the deadloop.

To configure kernel thread deadloop detection:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable kernel thread deadloop detection.

monitor kernel deadloop enable [ slot slot-number [ cpu cpu-number ] ]

The default for this command depends on the device model.

3.     (Optional.) Set the interval for identifying a kernel thread deadloop.

monitor kernel deadloop time interval [ slot slot-number [ cpu cpu-number ] ]

The default is 20 seconds.

4.     (Optional.) Disable kernel thread deadloop detection for a kernel thread.

monitor kernel deadloop exclude-thread tid [ slot slot-number [ cpu cpu-number ] ]

After enabled, kernel thread deadloop detection monitors all kernel threads by default.

 

Configuring kernel thread starvation detection

CAUTION

CAUTION:

The system detects whether or not kernel thread starvation occurs after the device is powered up. Inappropriate configuration of kernel thread starvation detection can cause service problems or system breakdown. Make sure you understand the impact of this configuration on your network before you configure kernel thread starvation detection.

 

Starvation occurs when a thread is unable to access shared resources.

Kernel thread starvation detection enables the system to detect and report thread starvation. If a thread is not executed within a specific interval, the system considers that a starvation has occurred, and generates a starvation message.

Thread starvation does not impact system operation. A starved thread can automatically run when certain conditions are met.

To configure kernel thread starvation detection:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable kernel thread starvation detection.

monitor kernel starvation enable [ slot slot-number [ cpu cpu-number ] ]

By default, the function is disabled.

3.     (Optional.) Set the interval for identifying a kernel thread starvation.

monitor kernel starvation time interval [ slot slot-number [ cpu cpu-number ] ]

The default is 120 seconds.

4.     (Optional.) Disable kernel thread starvation detection for a kernel thread.

monitor kernel starvation exclude-thread tid [ slot slot-number [ cpu cpu-number ] ]

After enabled, kernel thread starvation detection monitors all kernel threads by default.

 

Displaying and maintaining kernel threads

Execute display commands in any view and reset commands in user view.

 

Task

Command

Display kernel thread deadloop information.

display kernel deadloop show-number [ offset ] [ verbose ] [ slot slot-number [ cpu cpu-number ] ]

Display kernel thread deadloop detection configuration.

display kernel deadloop configuration [ slot slot-number [ cpu cpu-number ] ]

Display kernel thread exception information.

display kernel exception show-number [ offset ] [ verbose ] [ slot slot-number [ cpu cpu-number ] ]

Display kernel thread reboot information.

display kernel reboot show-number [ offset ] [ verbose ] [ slot slot-number [ cpu cpu-number ] ]

Display kernel thread starvation information.

display kernel starvation show-number [ offset ] [ verbose ] [ slot slot-number [ cpu cpu-number ] ]

Display kernel thread starvation detection configuration.

display kernel starvation configuration [ slot slot-number [ cpu cpu-number ] ]

Clear kernel thread deadloop information.

reset kernel deadloop [ slot slot-number [ cpu cpu-number ] ]

Clear kernel thread exception information.

reset kernel exception [ slot slot-number [ cpu cpu-number ] ]

Clear kernel thread reboot information.

reset kernel reboot [ slot slot-number [ cpu cpu-number ] ]

 

 


Configuring PoE

Overview

IEEE 802.3af-compliant power over Ethernet (PoE) enables a network device to supply power to terminals over twisted pair cables.

As shown in Figure 44, a PoE system includes the following elements:

·     PoE power supply—The PoE power supply provides power for the entire PoE system.

·     PSE—A power sourcing equipment (PSE) detects and classifies powered devices (PDs), supplies power to PDs, and monitors the PD power and connection status. PSEs include endpoint PSEs and midspan PSEs. H3C PSEs are endpoint PSEs.

·     PI—A power interface (PI) is a PoE-capable Ethernet interface on a PSE.

·     PD—A PD receives power from the PSE.

PDs include IP telephones, APs, portable chargers, POS terminals, and Web cameras.

You can also connect a PD to a redundant power source for reliability.

Figure 44 PoE system diagram

 

Feature and hardware compatibility

Hardware series

Model

PoE compatibility

WX1800H series

WX1804H

Yes

WX1810H

Yes

WX1820H

No

WX1840H

No

WX3800H series

WX3820H

WX3840H

No

WX5800H series

WX5860H

No

 

PoE configuration task list

You can configure a PI directly on the port or by configuring a PoE profile and applying the PoE profile to the PI. To configure one PI, configure it on the port. To configure multiple PIs in batches, use the PoE profile.

Before configuring PoE, make sure the PoE power supply and PSE are operating correctly. Otherwise, either you cannot configure PoE or the PoE configuration cannot take effect.

To configure PoE, perform the following tasks:

 

Tasks at a glance

(Required.) Enabling PoE for a PI

(Optional.) Enabling nonstandard PD detection

(Optional.) Configuring the maximum PI power

(Optional.) Configuring the PI priority policy

(Optional.) Configuring PoE monitoring

(Optional.) Configuring a PI by using a PoE profile:

·     Configuring a PoE profile

·     Applying a PoE profile

 

Enabling PoE for a PI

After you enable PoE for a PI, the system reserves and supplies power to the PD connected to the PI.

You can enable PoE for a PI when either of the following conditions is met:

·     The PI will not result in PSE power overload.

·     The PI will result in PSE power overload, but the PoE priority policy is enabled on the PI. For more information about the PI priority policy, see "Configuring the PI priority policy."

The PSE supplies power over the Category 3 or Category 5 twisted pair cable connected to a PI in the following modes:

·     Over signal wires—The PSE uses data pairs (pins 1, 2, 3, and 6) to supply DC power to PDs.

·     Over spare wires—The PSE uses spare pairs (pins 4, 5, 7, and 8) to supply DC power to PDs.

 

 

NOTE:

·     The device supports power transmission only over signal wires.

·     The power transmission mode varies by device model. A PSE can supply power to a PD directly only when the PSE and PD use the same power transmission mode. If the PSE and PD use different power transmission modes, you must change the order of the lines in the twisted pair cable to supply power to the PD.

 

To enable PoE for a PI:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter PI view.

interface interface-type interface-number

N/A

3.     Enable PoE for the PI.

poe enable

By default, PoE is disabled for a PI.

4.     (Optional.) Configure power transmission mode.

poe mode { signal | spare }

The default mode is power over signal cables (signal).

5.     (Optional.) Configure a description for the PD connected to the PI.

poe pd-description text

By default, no description is configured for the PD connected to the PI.

 

Enabling nonstandard PD detection

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable nonstandard PD detection.

poe legacy enable

By default, nonstandard PD detection is disabled. The PSE detects only IEEE 802.3af-compliant standard PDs and supplies power to them.

 

Configuring the maximum PI power

The following matrix shows the feature and hardware compatibility:

 

Hardware series

Model

Maximum PI power compatibility

WX1800H series

WX1804H

No

WX1810H

Yes

WX1820H

No

WX1840H

No

WX3800H series

WX3820H

WX3840H

No

 

The maximum PI power is the maximum power that a PI can provide to the connected PD. If the PD requires more power than the maximum PI power, the PI does not supply power to the PD.

To configure the maximum PI power:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter PI view.

interface interface-type interface-number

N/A

3.     (Optional.) Configure the maximum PI power.

poe max-power max-power

By default, the maximum PI power is 30000 millwatts.

 

Configuring the PI priority policy

The following matrix shows the feature and hardware compatibility:

 

Hardware series

Model

PI priority policy compatibility

WX1800H series

WX1804H

No

WX1810H

Yes

WX1820H

No

WX1840H

No

WX3800H series

WX3820H

WX3840H

No

 

The PI priority policy enables the PSE to perform priority-based power allocation to PIs when PSE power overload occurs. The priority levels for PIs are critical, high, and low in descending order.

When PSE power overload occurs, the PSE supplies power to PDs as follows:

·     If the PI priority policy is disabled, the PSE does not supply power to the newly-added or existing PD that causes PSE power overload.

·     If the PI priority policy is enabled, the PSE supplies power to PDs as follows:

?     If a PD being powered causes PSE power overload, the PSE stops supplying power to the PD.

?     If a newly-added PD causes PSE power overload, the PSE supplies power to PDs in priority descending order of the PIs to which they are connected. If the newly-added PD and a PD being powered have the same priority, the PD being powered takes precedence. If multiple PIs being powered have the same priority, the PIs with smaller IDs take precedence.

Before you configure a PI with critical priority, make sure the remaining power from the maximum PSE power minus the maximum powers of the existing PIs with critical priority is greater than maximum power of the PI.

Configuration for a PI whose power is preempted remains unchanged.

To configure the PI priority policy:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable the PI priority policy.

poe pd-policy priority

By default, the PI priority policy is disabled.

3.     Enter PI view.

interface interface-type interface-number

N/A

4.     (Optional.) Configure a priority for the PI.

poe priority { critical | high | low }

By default, the priority for a PI is low.

 

Configuring PoE monitoring

When the PoE monitoring function is enabled, the system monitors PSEs and PDs. If a specific value exceeds the threshold, the system automatically takes self-protection measures.

If a PSE starts or stops power supply to a PD, the system automatically sends a notification message. For more information, see "Configuring SNMP."

The system monitors PSE power utilization and sends notification messages when PSE power utilization exceeds or drops below the threshold. If PSE power utilization crosses the threshold multiple times in succession, the system sends notification messages only for the first crossing. For more information about the notification message, see "Configuring SNMP."

To configure a PSE power alarm threshold:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure a power alarm threshold for the PSE.

poe utilization-threshold utilization-threshold-value

By default, the power alarm threshold for the PSE is 80%.

 

Configuring a PI by using a PoE profile

The following matrix shows the feature and hardware compatibility:

 

Hardware series

Model

Compatibility with PI configuration by using a PoE profile

WX1800H series

WX1804H

No

WX1810H

Yes

WX1820H

No

WX1840H

No

WX3800H series

WX3820H

WX3840H

No

 

A PoE profile is a collection of configurations that contain multiple PoE features.

You can configure a PI either on the port or by using a PoE profile. If you configure a parameter twice with different methods, only the first configuration takes effect. The poe max-power max-power and poe priority { critical | high | low } commands must be configured using the same method.

The PoE profile is preferable for PI configuration in batches and PD-specific PI configuration.

·     You can apply a PoE profile to multiple PIs. PIs configured by the same PoE profile have the same PoE features.

·     You can define PoE configurations for a PD in a PoE profile, and apply the PoE profile to the PI to which the PD connects. This avoids reconfiguration when the PD is moved to another PI.

Configuring a PoE profile

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create a PoE profile, and enter PoE profile view.

poe-profile profile-name [ index ]

By default, no PoE profiles exist.

3.     Enable PoE.

poe enable

By default, this function is disabled.

4.     (Optional.) Configure the maximum PI power.

poe max-power max-power

For hardware compatibility with this command, see PoE commands in Network Management and Command Reference.

5.     (Optional.) Configure PoE power transmission mode.

poe mode { signal | spare }

The default mode is power over signal pins (signal).

6.     (Optional.) Configure PI priority.

poe priority { critical | high | low }

The default priority is low.

 

Applying a PoE profile

You can apply a PoE profile in system view or PI view. If you perform the operation in both views, the most recent operation takes effect. To apply a PoE profile to multiple PIs, perform the operation in system view. A PoE profile can be applied to multiple PIs, but a PI can have only one PoE profile.

To modify an applied PoE profile, first execute the undo apply poe-profile or undo apply poe-profile interface command to remove its application.

Applying a PoE profile to multiple PIs in system view

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Apply a PoE profile to one or multiple PIs.

apply poe-profile { index index | name profile-name } interface interface-range

By default, no PoE profile is applied to a PI.

 

Applying a PoE profile to a PI in PI view

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter PI view.

interface interface-type interface-number

N/A

3.     Apply the PoE profile to the interface.

apply poe-profile { index index | name profile-name }

By default, no PoE profile is applied to a PI.

 

Displaying and maintaining PoE

Execute display commands in any view.

 

Task

Command

Display general PSE information.

display poe device

Display the power supplying information for the specified PI.

display poe interface [ interface-type interface-number ]

Display power information for PIs.

display poe interface power [ interface-type interface-number ]

Display detailed PSE information.

display poe pse

Display all information about the PoE profile.

display poe-profile [ index index | name profile-name ]

Display all information about the PoE profile applied to the specified PI.

display poe-profile interface interface-type interface-number

 

PoE configuration example

Network requirements

As shown in Figure 45, configure PoE to meet the following requirements:

·     Enable the device to supply power to IP telephones and APs.

·     Enable the device to supply power to IP telephones first when overload occurs.

Figure 45 Network diagram

 

Configuration procedure

# Enable PoE on GigabitEthernet 1/0/1, GigabitEthernet 1/0/2, GigabitEthernet 1/0/3, and GigabitEthernet 1/0/4, and set the power supply priority to critical for GigabitEthernet 1/0/1.

[PSE] interface gigabitethernet 1/0/1

[PSE-GigabitEthernet1/0/1] poe enable

[PSE-GigabitEthernet1/0/1] poe priority critical

[PSE-GigabitEthernet1/0/1] quit

[PSE] interface gigabitethernet 1/0/2

[PSE-GigabitEthernet1/0/2] poe enable

[PSE-GigabitEthernet1/0/2] quit

[PSE] interface gigabitethernet 1/0/3

[PSE-GigabitEthernet1/0/3] poe enable

[PSE-GigabitEthernet1/0/3] quit

[PSE] interface gigabitethernet 1/0/4

[PSE-GigabitEthernet1/0/4] poe enable

[PSE-GigabitEthernet1/0/4] quit

Verifying the configuration

# Connect the IP telephones and APs to the PSE to verify that they can obtain power and operate correctly. (Details not shown.)

Troubleshooting PoE

Failure to set the priority of a PI to critical

Symptom

Power supply priority configuration for a PI failed.

Solution

To resolve the problem:

1.     Identify whether the priority has been configured through other methods. If the priority has been configured, remove the configuration.

2.     If the problem persists, contact H3C Support.

Failure to apply a PoE profile to a PI

Symptom

PoE profile application for a PI failed.

Solution

To resolve the problem:

1.     Identify whether some settings in the PoE profile have been configured. If they have been configured, remove the configuration.

2.     Identify whether the settings in the PoE profile meet the requirements of the PI. If they do not, modify the settings in the PoE profile.

3.     Identify whether another PoE profile is already applied to the PI. If it is, remove the application.

4.     If the problem persists, contact H3C Support.


Configuring flow log

Flow log records users' access to external networks based on flows. Each flow is identified by a 5-tuple of the source IP address, destination IP address, source port, destination port, and protocol number.

Flow log creates entries based on NAT sessions. You can export these entries to the information center or log hosts.

Flow log has two versions: version 1.0 and version 3.0. Compared to version 1.0, version 3.0 of flow log provides flow statistics. Table 16 and Table 17 show the fields available in the versions.

Table 16 Flow log 1.0 fields

Field

Description

SrcIP

Source IP address before NAT.

DestIP

Destination IP address before NAT.

SrcPort

Source TCP/UDP port number before NAT.

DestPort

Destination TCP/UDP port number before NAT.

StartTime

Start time of the flow, in seconds.

EndTime

End time of the flow, in seconds.

This field is 0 if the Operator field is 6 (regular connectivity check record for the active flow).

Protocol

Protocol number.

Operator

Reasons why a flow log entry was generated:

·     0—Reserved.

·     1—Flow was ended normally.

·     2—Flow was aged out because of aging timer expiration.

·     3—Flow was aged out because of configuration change or manual deletion.

·     4—Flow was aged out because of insufficient resources.

·     5—Reserved.

·     6—Regular connectivity check record for the active flow.

·     7—Flow was deleted because a new flow was created when the flow table was full.

·     8—Flow was created.

·     FE—Other reasons.

·     10-FE-1Reserved for future use.

Reserved

Reserved for future use.

 

Table 17 Flow log 3.0 fields

Field

Description

Protocol

Protocol number.

Operator

Reasons why a flow log was generated:

·     0—Reserved.

·     1—Flow was ended normally.

·     2—Flow was aged out because of aging timer expiration.

·     3—Flow was aged out because of configuration change.

·     4—Flow was aged out because of insufficient resources.

·     5—Reserved.

·     6—Regular connectivity check record for the active flow.

·     7—Flow was deleted because a new flow was created when the flow table was full.

·     8—Flow was created.

·     FE—Other reasons.

·     10-FE-1Reserved for future use.

IPVersion

IP packet version.

TosIPv4

ToS field of the IPv4 packet.

SourceIP

Source IP address before NAT.

SrcNatIP

Source IP address after NAT.

DestIP

Destination IP address before NAT.

DestNatIP

Destination IP address after NAT.

SrcPort

Source TCP/UDP port number before NAT.

SrcNatPort

Source TCP/UDP port number after NAT.

DestPort

Destination TCP/UDP port number before NAT.

DestNatPort

Destination TCP/UDP port number after NAT.

StartTime

Start time of the flow, in seconds.

EndTime

End time of the flow, in seconds.

This field is 0 when the Operator field is 6 (regular connectivity check record for the active flow).

InTotalPkg

Number of packets received for the session.

InTotalByte

Number of bytes received for the session.

OutTotalPkg

Number of packets sent for the session.

OutTotalByte

Number of bytes sent for the session.

InVPNID

ID of the source VPN instance.

OutVPNID

ID of the destination VPN instance.

Reserved1

Reserved2

Reserved3

Reserved for future use.

 

Flow log configuration task list

Tasks at a glance

(Required.) Specifying a flow log export destination

·     Specifying a log host as the flow log export destination

·     Specifying the information center as the flow log export destination

(Optional.) Configuring the flow log version

(Optional.) Specifying a source IP address for flow log packets

(Optional.) Configuring the timestamp of flow logs

(Optional.) Enabling load balancing for flow log entries

(Optional.) Configuring flow log host groups

 

Configuration prerequisites

Before you configure the flow log feature, complete the following tasks:

·     Enable NAT logging by using the nat log enable command.

·     Enable the following NAT logging features:

?     Logging of active NAT flows (nat log flow-active).

?     Logging of NAT session establishment events (nat log flow-begin).

?     Logging of NAT session removal events (nat log flow-end).

For more information about the NAT logging commands, see Layer 3—IP Services Command Reference.

Specifying a flow log export destination

You can export flow log entries to a log host or the information center, but not both. If you configure both methods, the system exports flow log entries to the information center.

·     If the destination is a log host, flow log entries are sent as binary characters in UDP. One UDP packet can contain multiple log entries.

·     If the destination is the information center, flow log entries are converted to syslog entries in ASCII format, with the informational severity level. With the information center, you can specify multiple output destinations, including the console, log host, and log file. For more information about the information center, see "Configuring the information center."

Log entries in ASCII format are human readable. However, the log data volume is higher in ASCII format than in binary format.

Specifying a log host as the flow log export destination

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Specify a log host as the destination for flow log export.

userlog flow export host { hostname | ipv4-address | ipv6 ipv6-address } port udp-port

By default, no log hosts are specified.

To specify multiple log hosts, repeat this step.

 

Specifying the information center as the flow log export destination

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Specify the information center as the destination for flow log export.

userlog flow syslog

By default, flow log entries are not exported.

 

Configuring the flow log version

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure the flow log version.

userlog flow export version version-number

The default flow log version is 1.0.

Make sure the specified flow log version is supported on the log host.

If you configure the flow log version multiple times, the most recent configuration takes effect.

 

Specifying a source IP address for flow log packets

By default, the source IP address for flow log packets is the IP address of their outgoing interface. For the log hosts to filter log entries by log sender, specify a source IP address for all flow log packets.

H3C recommends that you use a Loopback interface's address as the source IP address for flow log packets. A Loopback interface is always up. The setting avoids export failure on interfaces that might go down.

To configure the source IP address for flow log packets:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Specify a source IP address for flow log packets.

userlog flow export source-ip ip-address

By default, the source IP address for flow log packets is the IP address of their outgoing interface.

 

Configuring the timestamp of flow logs

The device uses either the local time or the UTC time in the timestamp of flow logs.

·     UTC time—Standard Greenwich Mean Time (GMT).

·     Local time—Standard GMT plus or minus the time zone offset.

The time zone offset can be configured by using the clock timezone command. For more information, see Fundamentals Command Reference.

By default, the UTC time is used.

To configure the device to use the local time in the flow log timestamp:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure the device to use the local time in the flow log timestamp.

userlog flow export timestamp localtime

By default, the UTC time is used in the flow log timestamp.

 

Enabling load balancing for flow log entries

By default, the device sends a copy of each flow log entry to all available log hosts. When one log host fails, other log hosts still have complete flow log entries.

In load balancing mode, flow log entries are distributed among log hosts based on the source IP addresses (before NAT) that are recorded in the entries. The flow log entries generated for the same source IP address are sent to the same log host. If a log host goes down, the flow logs sent to it will be lost.

To enable load balancing for flow log entries:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable load balancing for flow log entries.

userlog flow export load-balancing

By default, load balancing is disabled.

 

Configuring flow log host groups

About flow log host group

By default, the device sends a copy of each flow log entry to all available log hosts. To filter logs and reduce the log sending and processing workload of the device, configure the flow log host group feature.

The flow log host group feature allows you to classify flow log hosts into groups and specify an ACL for each group. A flow log matches a log host group if it matches the group's ACL, and it is sent only to the log hosts in the matching group.

If a flow log matches multiple log host groups, the device sends the log to the group that comes first in alphabetical order of the matching group names.

If a flow log does not match any log host groups, the device ignores the log host group configuration and sends the log to all configured log hosts.

If load balancing is enabled, flow logs sent to a log host group will be load-shared among the log hosts in the group. Flow logs generated for the same source IP address are sent to the same log host.

Prerequisites

Before you configure flow log host groups, complete the following tasks:

·     Configure the ACLs to be used by the flow log host groups.

·     Use the userlog flow export host command to configure the log hosts to be assigned to the flow log host groups.

Configuring an IPv4 flow log host group

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create an IPv4 flow log host group and enter its view.

userlog host-group host-group-name acl { name acl-name | number acl-number }

By default, no IPv4 flow log host groups exist.

3.     Assign an IPv4 log host to the flow log host group.

userlog host-group host flow { hostname | ipv4-address }

By default, an IPv4 flow log host group does not contain any log hosts.

 

Configuring an IPv6 flow log host group

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create an IPv6 flow log host group and enter its view.

userlog host-group ipv6 host-group-name acl { name acl-name | number acl-number }

By default, no IPv6 flow log host groups exist.

3.     Assign an IPv6 log host to the flow log host group.

userlog host-group host flow ipv6 { hostname | ipv6-address }

By default, an IPv6 flow log host group does not contain any log hosts.

 

Displaying and maintaining flow log

Execute display commands in any view.

 

Task

Command

Display flow log configuration and statistics.

display userlog export

Display flow log host group information.

display userlog host-group [ ipv6 ] [ host-group-name ]

Clear flow log statistics.

reset userlog flow export

 

Flow log configuration example

Network requirements

As shown in Figure 46, configure flow log on the AC to send flow log entries generated for the user to the log host.

Figure 46 Network diagram

 

Configuration procedure

# Configure IP addresses, as shown in the network diagram. Make sure the devices can reach each other. (Details not shown.)

# Enable NAT logging.

<AC> system-view

[AC] nat log enable

# Enable NAT logging for session establishment events, session removal events, and active flows.

[AC] nat log flow-begin

[AC] nat log flow-end

[AC] nat log flow-active 10

# Set the flow log version to 3.0.

[AC] userlog flow export version 3

# Specify the log host at 1.2.3.6 as the destination for flow log export. Set the UDP port number to 2000.

[AC] userlog flow export host 1.2.3.6 port 2000

# Specify 2.2.2.2 as the source IP address for flow log packets.

[AC] userlog flow export source-ip 2.2.2.2

[AC] quit

Verifying the configuration

# Display the flow log configuration and statistics.

<AC> display userlog export

Flow:                                                                          

  Export flow log as UDP Packet.                                               

  Version: 3.0                                                                 

  Source ipv4 address: 2.2.2.2                                                 

  Source ipv6 address:                                                         

  Log load balance function: Disabled                                          

  Local time stamp: Disabled                                                   

  Log host numbers: 1

 

  Log host 1:

    Host /Port: 1.2.3.6/2000

    Total logs/UDP packets exported: 112/87

Example: Configuring flow log export to a flow log host group

Network configuration

As shown in Figure 47, configure a flow log host group on the device to send flow log entries generated for the user only to Log Host 1.

Figure 47 Network diagram

 

Procedure

# Configure IP addresses, as shown in Figure 47. Make sure the device, user, and the log host can reach one another. (Details not shown.)

# Enable NAT logging.

<Device> system-view

[Device] nat log enable

# Enable NAT logging for session establishment events, session removal events, and active flows.

[Device] nat log flow-begin

[Device] nat log flow-end

[Device] nat log flow-active 10

# Specify Log Host 1 and Log Host 2 for flow log export.

[Device] userlog flow export host 1.1.1.2 port 2000

[Device] userlog flow export host 2.2.2.2 port 2000

# Specify 3.3.3.3 as the source IP address for flow log packets.

[Device] userlog flow export source-ip 3.3.3.3

# Create ACL 2000 to match packets sent by the user.

[Device] acl basic 2000

[Device-acl-ipv4-basic-2000] rule 1 permit source 169.1.1.2 0.0.0.0

[Device-acl-ipv4-basic-2000] quit

# Create an IPv4 flow log host group named test and specify ACL 2000 for it.

[Device] userlog host-group test acl number 2000

# Assign Log Host 1 to flow log host group test.

[Device-userlog-host-group-test] userlog host-group host flow 1.1.1.2

[Device-userlog-host-group-test] quit

Verifying the configuration

# Display information about flow log host group test.

[Device] display userlog host-group test

Userlog host-group test:

  ACL number: 2000

 

  Flow log host numbers: 1

 

    Log host 1:

      Host/port: 1.1.1.2/2000

# After the user comes online, display flow log export statistics.

[Device] display userlog export

Flow:

  Export flow log as UDP Packet.

  Version: 1.0

  Source ipv4 address: 3.3.3.3

  Source ipv6 address:

  Log load balance function: Disabled

  Local time stamp: Disabled

  Log host numbers: 2

 

  Log host 1:

    Host/Port: 1.1.1.2/2000

    Total logs/UDP packets exported: 13/13

 

  Log host 2:

    Host/Port: 2.2.2.2/2000

    Total logs/UDP packets exported: 0/0

 


Configuring the packet capture

A CF card is used as an example in this chapter. For information about the storage media supported by the device, see file system management in Fundamentals Configuration Guide.

Overview

The packet capture feature captures incoming packets that are to be forwarded in CPU. The feature displays the captured packets in real time, and allows you to save the captured packets to a .pcap file for future analysis.

Packet capture modes

You can configure packet capture for only one user at a time.

Local packet capture

Local packet capture saves the captured packets to a remote file on an FTP server, to a local file, or displays the captured packets at the CLI.

Remote packet capture

Remote packet capture displays the captured packets on a Wireshark client. Before using remote packet capture, you must install the Wireshark software on a PC and connect the PC to the device to be used to capture packets. The device sends the packet data to be displayed to the Wireshark client.

Filter elements

The packet capture supports capture filters and display filters. You can use expressions to match packets to capture or display.

A capture or display filter contains a keyword string or multiple keyword strings that are connected by operators.

Keywords include the following types:

·     Qualifiers—Fixed keyword strings. For example, you must use the ip qualifier to specify the IPv4 protocol.

·     Variables—Values supplied by users in the required format. For example, you can set an IP address to 2.2.2.2 or any other valid values.

A variable must be modified by one or multiple qualifiers. For example, to capture any packets sent from the host at 2.2.2.2, use the filter src host 2.2.2.2.

Operators include the following types:

·     Logical operatorsPerform logical operations, such as the AND operation.

·     Arithmetic operatorsPerform arithmetic operations, such as the ADD operation.

·     Relational operatorsIndicate the relation between keyword strings. For example, the = operator indicates equality.

This document provides basic information about these elements. For more information about capture and display filters, go to the following websites:

·     http://wiki.wireshark.org/CaptureFilters.

·     http://wiki.wireshark.org/DisplayFilters.

Capture filter keywords

Table 18 and Table 19 describe the qualifiers and variables for capture filters, respectively.

Table 18 Qualifiers for capture filters

Category

Description

Examples

Protocol

Matches a protocol.

If you do not specify a protocol qualifier, the filter matches any supported protocols.

·     arp—Matches ARP.

·     icmp—Matches ICMP.

·     ip—Matches IPv4.

·     ipv6—Matches IPv6.

·     tcp—Matches TCP.

·     udp—Matches UDP.

Direction

Matches packets based on its source or destination location (an IP address or port number).

If you do not specify a direction qualifier, the src or dst qualifier applies.

·     src—Matches the source IP address field.

·     dst—Matches the destination IP address field.

·     src or dst—Matches the source or destination IP address field.

NOTE:

The src or dst qualifier applies if you do not specify a direction qualifier. For example, port 23 is equivalent to src or dst port 23.

Type

Specifies the direction type.

·     host—Matches the IP address of a host.

·     net—Matches an IP subnet.

·     port—Matches a service port number.

·     portrange—Matches a service port range.

NOTE:

The host qualifier applies if you do not specify any type qualifier. For example, src 2.2.2.2 is equivalent to src host 2.2.2.2.

To specify an IPv6 subnet, you must specify the net qualifier.

Others

Any other qualifiers than the previously described qualifiers.

·     broadcast—Matches broadcast packets.

·     multicast—Matches multicast and broadcast packets.

·     less—Matches packets that are less than or equal to a specific size.

·     greater—Matches packets that are greater than or equal to a specific size.

·     len—Matches the packet length.

·     vlan—Matches VLAN packets.

 

 

NOTE:

The broadcast, multicast, and all protocol qualifiers cannot modify variables.

 

Table 19 Variable types for capture filters

Variable type

Description

Examples

Integer

Represented in binary, octal, decimal, or hexadecimal notation.

The port 23 expression matches traffic sent to or from port number 23.

Integer range

Represented by hyphenated integers.

The portrange 100-200 expression matches traffic sent to or from any ports in the range of 100 to 200.

IPv4 address

Represented in dotted decimal notation.

The src 1.1.1.1 expression matches traffic sent from the IPv4 host at 1.1.1.1.

IPv6 address

Represented in colon hexadecimal notation.

The dst host 1::1 expression matches traffic sent to the IPv6 host at 1::1.

IPv4 subnet

Represented by an IPv4 network ID or an IPv4 address with a mask.

Both of the following expressions match traffic sent to or from the IPv4 subnet 1.1.1.0/24:

·     src 1.1.1.

·     src net 1.1.1.0/24.

IPv6 network segment

Represented by an IPv6 address with a prefix length.

The dst net 1::/64 expression matches traffic sent to the IPv6 network 1::/64.

 

Capture filter operators

Capture filters support logical operators (Table 20), arithmetic operators (Table 21), and relational operators (Table 22). Logical operators can use both alphanumeric and nonalphanumeric symbols. The arithmetic and relational operators can use only nonalphanumeric symbols.

Logical operators are left associative. They group from left to right. The not operator has the highest priority. The and and or operators have the same priority.

Table 20 Logical operators for capture filters

Nonalphanumeric symbol

Alphanumeric symbol

Description

!

not

Reverses the result of a condition.

Use this operator to capture traffic that matches the opposite value of a condition.

For example, to capture non-HTTP traffic, use not port 80.

&&

and

Joins two conditions.

Use this operator to capture traffic that matches both conditions.

For example, to capture non-HTTP traffic that is sent to or from 1.1.1.1, use host 1.1.1.1 and not port 80.

||

or

Joins two conditions.

Use this operator to capture traffic that matches either of the conditions.

For example, to capture traffic that is sent to or from 1.1.1.1 or 2.2.2.2, use host 1.1.1.1 or host 2.2.2.2.

 

Table 21 Arithmetic operators for capture filters

Nonalphanumeric symbol

Description

+

Adds two values.

-

Subtracts one value from another.

*

Multiplies one value by another.

/

Divides one value by another.

&

Returns the result of the bitwise AND operation on two integral values in binary form.

|

Returns the result of the bitwise OR operation on two integral values in binary form.

<< 

Performs the bitwise left shift operation on the operand to the left of the operator. The right-hand operand specifies the number of bits to shift.

>> 

Performs the bitwise right shift operation on the operand to the left of the operator. The right-hand operand specifies the number of bits to shift.

[ ]

Specifies a byte offset relative to a protocol layer. This offset indicates the byte where the matching begins.

You must enclose the offset value in the brackets and specify a protocol qualifier. For example, ip[6] matches the seventh byte of payload in IPv4 packets (the byte that is six bytes away from the beginning of the IPv4 payload).

 

Table 22 Relational operators for capture filters

Nonalphanumeric symbol

Description

=

Equal to.

For example, ip[6]=0x1c matches an IPv4 packet if its seventh byte of payload is equal to 0x1c.

!=

Not equal to.

For example, len!=60 matches a packet if its length is not equal to 60 bytes.

Greater than.

For example, len>100 matches a packet if its length is greater than 100 bytes.

Less than.

For example, len<100 matches a packet if its length is less than 100 bytes.

>=

Greater than or equal to.

For example, len>=100 matches a packet if its length is greater than or equal to 100 bytes.

<=

Less than or equal to.

For example, len<=100 matches a packet if its length is less than or equal to 100 bytes.

 

Display filter keywords

Table 23 and Table 24 describe the qualifiers and variables for display filters, respectively.

Table 23 Qualifiers for display filters

Category

Description

Examples

Protocol

Matches a protocol.

·     eth—Matches Ethernet.

·     ftp—Matches FTP.

·     icmp—Matches ICMP.

·     ip—Matches IPv4.

·     ipv6—Matches IPv6.

·     tcp—Matches TCP.

·     telnet—Matches Telnet.

·     udp—Matches UDP.

Packet field

Matches a field in packets by using a dotted string in the protocol.field[.level1-subfield]…[.leveln-subfield] format.

·     tcp.flags.syn—Matches the SYN bit in the flags field of TCP.

·     tcp.port—Matches the source or destination port field.

 

 

NOTE:

The protocol qualifiers cannot modify variables.

 

Table 24 Variable types for display filters

Variable type

Description

Integer

Represented in binary, octal, decimal, or hexadecimal notation.

For example, to display IP packets that are less than or equal to 1500 bytes, use one of the following expressions:

·     ip.len le 1500.

·     ip.len le 02734.

·     ip.len le 0x436.

Boolean

This variable type has two values: true or false.

This variable type applies if you use a packet field string alone to identify the presence of a field in a packet.

·     If the field is present, the match result is true. The filter displays the packet.

·     If the field is not present, the match result is false. The filter does not display the packet.

For example, to display TCP packets that contain the SYN field, use tcp.flags.syn.

MAC address (six bytes)

Uses colons (:), dots (.), or hyphens (-) to break up the MAC address into two or four segments.

For example, to display packets that contain a destination MAC address of ffff.ffff.ffff, use one of the following expressions:

·     eth.dst==ff:ff:ff:ff:ff:ff.

·     eth.dst==ff-ff-ff-ff-ff-ff.

·     eth.dst ==ffff.ffff.ffff.

IPv4 address

Represented in dotted decimal notation.

For example:

·     To display IPv4 packets that are sent to or from 192.168.0.1, use ip.addr==192.168.0.1.

·     To display IPv4 packets that are sent to or from 129.111.0.0/16, use ip.addr==129.111.0.0/16.

IPv6 address

Represented in colon hexadecimal notation.

For example:

·     To display IPv6 packets that are sent to or from 1::1, use ipv6.addr==1::1.

·     To display IPv6 packets that are sent to or from 1::/64, use ipv6.addr==1::/64.

String

Character string.

For example, to display HTTP packets that contain the string HTTP/1.1 for the request version field, use http.request version=="HTTP/1.1".

 

Display filter operators

Display filters support logical operators (Table 25) and relational operators (Table 26). Both operator types can use alphanumeric and nonalphanumeric symbols.

Logical operators are left associative. They group from left to right. Table 25 displays logical operators by priority, from the highest to the lowest. The and and or operators have the same priority.

Table 25 Logical operators for display filters

Nonalphanumeric

symbol

Alphanumeric

symbol

Description

[ ]

No alphanumeric symbol is available.

Used with protocol qualifiers. For more information, see "The proto[…] expression."

!

not

Displays packets that do not match the condition connected to this operator.

&&

and

Joins two conditions.

Use this operator to display traffic that matches both conditions.

||

or

Joins two conditions.

Use this operator to display traffic that matches either of the conditions.

 

Table 26 Relational operators for display filters

Nonalphanumeric

symbol

Alphanumeric

symbol

Description

==

eq

Equal to.

For example, ip.src==10.0.0.5 displays packets with the source IP address as 10.0.0.5.

!=

ne

Not equal to.

For example, ip.src!=10.0.0.5 displays packets whose source IP address is not 10.0.0.5.

gt

Greater than.

For example, frame.len>100 displays frames with a length greater than 100 bytes.

lt

Less than.

For example, frame.len<100 displays frames with a length less than 100 bytes.

>=

ge

Greater than or equal to.

For example, frame.len ge 0x100 displays frames with a length greater than or equal to 256 bytes.

<=

le

Less than or equal to.

For example, frame.len le 0x100 displays frames with a length less than or equal to 256 bytes.

 

Building a capture filter

This section provides the most commonly used expression types for capture filters.

Logical expression

Use this type of expression to capture packets that match the result of logical operations.

Logical expressions contain keywords and logical operators. For example:

·     not port 23 and not port 22—Captures packets with a port number that is not 23 or 22.

·     port 23 or icmp—Captures packets with a port number 23 or ICMP packets.

In a logical expression, a qualifier can modify more than one variable connected by its nearest logical operator. For example, to capture packets sourced from IPv4 address 192.168.56.1 or IPv4 network 192.168.27, use either of the following expressions:

·     src 192.168.56.1 or 192.168.27.

·     src 192.168.56.1 or src 192.168.27.

The expr relop expr expression

Use this type of expression to capture packets that match the result of arithmetic operations.

This expression contains keywords, arithmetic operators (expr), and relational operators (relop). For example, len+100>=200 captures packets that are greater than or equal to 100 bytes.

The proto [ expr:size ] expression

Use this type of expression to capture packets that match the result of arithmetic operations on a number of bytes relative to a protocol layer.

This type of expression contains the following elements:

·     proto—Specifies a protocol layer.

·     []—Performs arithmetic operations on a number of bytes relative to the protocol layer.

·     expr—Specifies the arithmetic expression.

·     size—Specifies the byte offset. This offset indicates the number of bytes relative to the protocol layer. The operation is performed on the specified bytes. The offset is set to 1 byte if you do not specify an offset.

For example, ip[0]&0xf !=5 captures an IP packet if the result of ANDing the first byte with 0x0f is not 5.

To match a field, you can specify a field name for expr:size. For example, icmp[icmptype]=0x08 captures ICMP packets that contain a value of 0x08 in the Type field.

The vlan vlan_id expression

Use this type of expression to capture 802.1Q tagged VLAN traffic.

This type of expression contains the vlan vlan_id keywords and logical operators. The vlan_id variable is an integer that specifies a VLAN ID. For example, vlan 1 and ip6 captures IPv6 packets in VLAN 1.

To capture 802.1Q tagged traffic, you must use the vlan vlan_id expression prior to any other expressions. An expression matches untagged packets if it does not follow a vlan vlan_id expression. For example:

·     vlan 1 and !tcp—Captures VLAN 1-tagged non-TCP packets.

·     icmp and vlan 1—Captures untagged ICMP packets that are VLAN 1 tagged. This expression does not capture any packets because no packets can be both tagged and untagged.

Building a display filter

This section provides the most commonly used expression types for display filters.

Logical expression

Use this type of expression to display packets that match the result of logical operations.

Logical expressions contain keywords and logical operators. For example, ftp or icmp displays all FTP packets and ICMP packets.

Relational expression

Use this type of expression to display packets that match the result of comparison operations.

Relational expressions contain keywords and relational operators. For example, ip.len<=28 displays IP packets that contain a value of 28 or fewer bytes in the length field.

Packet field expression

Use this type of expression to display packets that contain a specific field.

Packet field expressions contain only packet field strings. For example, tcp.flags.syn displays all TCP packets that contain the SYN bit field.

The proto[…] expression

Use this type of expression to display packets that contain specific field values.

This type of expression contains the following elements:

·     proto—Specifies a protocol layer or packet field.

·     []—Matches a number of bytes relative to a protocol layer or packet field. Values for the bytes to be matched must be a hexadecimal integer string. The expression in brackets can use the following formats:

?     [n:m]—Matches a total of m bytes after an offset of n bytes from the beginning of the specified protocol layer or field. To match only 1 byte, you can use both [n] and [n:1] formats. For example, eth.src[0:3]==00:00:83 matches an Ethernet frame if the first three bytes of its source MAC address are 0x00, 0x00, and 0x83. The eth.src[2] == 83 expression matches an Ethernet frame if the third byte of its source MAC address is 0x83.

?     [n-m]—Matches a total of (m-n+1) bytes, starting from the (n+1)th byte relative to the beginning of the specified protocol layer or packet field. For example, eth.src[1-2]==00:83 matches an Ethernet frame if the second and third bytes of its source MAC address are 0x00 and 0x83, respectively.

Packet capture configuration task list

Tasks at a glance

(Required.) Perform one of the following tasks:

·     Configuring local packet capture on an AP radio

·     Configuring remote packet capture on an AP radio

 

Configuring local packet capture on an AP radio

Perform this task to capture incoming packets on an AP radio and save the captured packets to a file on an FTP server. To display the captured packets, use the Wireshark client connected to the FTP server. To stop the capture while it is capturing packets, use the packet-capture stop command.

To configure local packet capture on an AP radio:

 

Task

Command

Remarks

Configure local packet capture on an AP radio.

packet-capture local ap ap-name radio radio-id [ capture-filter capt-expression | limit-frame-size bytes | autostop filesize kilobytes | autostop duration seconds ] * write url url [ username username [ password { cipher | simple } key ] ]

After this command is executed, you can still configure other commands from the CLI. The operation does not affect the packet capture.

 

Configuring remote packet capture on an AP radio

Perform this task to enable remote packet capture and use Wireshark to display captured packets. To stop the capture while it is capturing packets, use the packet-capture stop command.

To configure remote packet capture on an AP radio:

 

Task

Command

Configure remote packet capture on an AP radio.

packet-capture remote ap ap-name radio radio-id [ port port ]

 

To display the captured packets, perform the following tasks:

1.     Connect the Wireshark client to the device that captures packets.

2.     Start Wireshark and select Capture > Options.

3.     Select Remote from the Interface list.

4.     Enter the IP address of the remote interface and the RPCAP service port number on the window that appears, and click OK.

Make sure the interface IP address is reachable for the Wireshark. You can use the default RPCAP service port 2002.

5.     Click Start.

Figure 48 Configuring Wireshark capture options

 

Displaying and maintaining packet capture

Execute display commands in any view.

 

Task

Command

Display the packet capture status.

display packet-capture status

 

Packet capture configuration examples

Local packet capture configuration example

Network requirements

As shown in Figure 49, enable local packet capture on radio 1 of the AP to capture 1 KB of TCP packets sourced from 192.168.20.173. The switch acts as the FTP server for storing the captured packets sent by the AP.

Figure 49 Network diagram

 

Configuration procedure

1.     Configure the switch:

# Create a device management user.

<Switch> system-view

[Switch] local-user abc class manage

# Set a password for the local user to 123456 in plain text.

[Switch-luser-abc] password simple 123456

# Specify the user role for the user as network-admin and specify a working directory for the user.

[Switch-luser-abc] authorization-attribute user-role network-admin work-directory cfa0:/

# Specify the service type for the user as ftp.

[Switch-luser-abc] service-type ftp

[Switch-luser-abc] quit

# Enable the FTP server on the switch.

[Switch] ftp server enable

[Switch] quit

2.     On radio 1 of the AP, capture 1 KB of TCP packets sourced from 192.168.20.173. Specify the username as abc and the password as 123456. Save the captured packets in the abc.pcap file on the FTP server at 10.1.1.1.

<AC> packet-capture local ap ap1 radio 1 autostop filesize 1 capture-filter "src 192.168.20.173 and tcp" write url ftp://10.1.1.1/abc.pcap username abc password simple 123456

Verifying the configuration

# Execute the display packet-capture status command to display the capture status.

# Connect the Wireshark client to the FTP server and display the captured packets on the PC. (Details not shown.)

Remote packet capture configuration example

Network requirements

As shown in Figure 50, enable remote packet capture on radio 1 of the AP and use Wireshark to display the captured packets.

Figure 50 Network diagram

 

Configuration procedure

1.     Configure remote packet capture on radio 1 of the AP and specify the RPCAP service port number as 2014.

<AC> packet-capture remote ap ap1 radio 1 port 2014

2.     Display captured packets on the PC:

a.     Start Wireshark and select Capture > Options.

b.     Select Remote from the Interface list.

c.     Enter the IP address 10.1.1.1 and the port number 2014, and click OK.

d.     Click Start.

The captured packets are displayed on the page that appears.

Figure 51 Displaying the captured packets on the Wireshark

 

 


Configuring the information center

The information center on a device classifies and manages logs for all modules so that network administrators can monitor network performance and troubleshoot network problems.

Overview

The information center receives logs generated by source modules and outputs logs to different destinations according to user-defined output rules. You can classify, filter, and output logs based on source modules. To view the supported source modules, use info-center source ?.

Figure 52 Information center diagram

 

By default, the information center is enabled. It affects system performance to some degree while processing large amounts of information. If the system resources are insufficient, disable the information center to save resources.

Log types

Logs are classified into the following types:

·     Common logs—Record common system information. Unless otherwise specified, the term "logs" in this document refers to common logs.

·     Diagnostic logs—Record debug messages.

·     Security logs—Record security information, such as authentication and authorization information.

·     Hidden logs—Record log information not displayed on the terminal, such as input commands.

·     Trace logs—Record system tracing and debug messages, which can be viewed only after the devkit package is installed.

·     Custom logs—Record vendor-specific information.

Log levels

Logs are classified into eight severity levels from 0 through 7 in descending order. The information center outputs logs with a severity level that is higher than or equal to the specified level. For example, if you specify a severity level of 6 (informational), logs that have a severity level from 0 to 6 are output.

Table 27 Log levels

Severity value

Level

Description

0

Emergency

The system is unusable. For example, the system authorization has expired.

1

Alert

Action must be taken immediately. For example, traffic on an interface exceeds the upper limit.

2

Critical

Critical condition. For example, the device temperature exceeds the upper limit, the power module fails, or the fan tray fails.

3

Error

Error condition. For example, the link state changes.

4

Warning

Warning condition. For example, an interface is disconnected, or the memory resources are used up.

5

Notification

Normal but significant condition. For example, a terminal logs in to the device, or the device reboots.

6

Informational

Informational message. For example, a command or a ping operation is executed.

7

Debugging

Debug message.

 

Log destinations

The system outputs logs to the following destinations: console, monitor terminal, log buffer, log host, and log file. Log output destinations are independent and you can configure them after enabling the information center.

Default output rules for logs

A log output rule specifies the source modules and severity level of logs that can be output to a destination. Logs matching the output rule are output to the destination. Table 28 shows the default log output rules.

Table 28 Default output rules

Destination

Log source modules

Output switch

Severity

Console

All supported modules

Enabled

Debug

Monitor terminal

All supported modules

Disabled

Debug

Log host

All supported modules

Enabled

Informational

Log buffer

All supported modules

Enabled

Informational

Log file

All supported modules

Enabled

Informational

 

Default output rules for diagnostic logs

Diagnostic logs can only be output to the diagnostic log file, and cannot be filtered by source modules and severity levels. Table 29 shows the default output rule for diagnostic logs.

Table 29 Default output rule for diagnostic logs

Destination

Log source modules

Output switch

Severity

Diagnostic log file

All supported modules

Enabled

Debug

 

Default output rules for security logs

Security logs can only be output to the security log file, and cannot be filtered by source modules and severity levels. Table 30 shows the default output rule for security logs.

Table 30 Default output rule for security logs

Destination

Log source modules

Output switch

Severity

Security log file

All supported modules

Disabled

Debug

 

Default output rules for hidden logs

Hidden logs can be output to the log host, the log buffer, and the log file. Table 31 shows the default output rules for hidden logs.

Table 31 Default output rules for hidden logs

Destination

Log source modules

Output switch

Severity

Log host

All supported modules

Enabled

Informational

Log buffer

All supported modules

Enabled

Informational

Log file

All supported modules

Enabled

Informational

 

Default output rules for trace logs

Trace logs can only be output to the trace log file, and cannot be filtered by source modules and severity levels. Table 32 shows the default output rules for trace logs.

Table 32 Default output rules for trace logs

Destination

Log source modules

Output switch

Severity

Trace log file

All supported modules

Enabled

Debugging

 

Default output rules for custom logs

Custom logs can only be output to a log host, and cannot be filtered by source modules and severity levels. Table 33 shows the default output rules for custom logs.

Table 33 Default output rules for custom logs

Destination

Log source modules

Output switch

Severity

Log host

Specific operations

Enabled

Debugging

 

Log formats

The format of logs varies by output destinations. Table 34 shows the original format of log information, which might be different from what you see. The actual format varies by the log resolution tool used.

Table 34 Log formats

Output destination

Format

Example

Console, monitor terminal, log buffer, or log file

Prefix Timestamp Sysname Module/Level/Mnemonic: Content

%Nov 24 14:21:43:502 2010 H3C SYSLOG/6/SYSLOG_RESTART: System restarted –-

H3C Comware Software.

Log host

·     Standard format:
<PRI>Timestamp Sysname %%vvModule/Level/Mnemonic: Source; Content

·     unicom format:
<PRI>Timestamp Hostip vvModule/Level/Serial_number: Content

·     cmcc format:
<PRI>Timestamp Sysname %vvModule/Level/Mnemonic: Source Content

·     Standard format:
<190>Nov 24 16:22:21 2010 H3C %%10SYSLOG/6/SYSLOG_RESTART: -DevIP=1.1.1.1; System restarted –-

H3C Comware Software.

·     unicom format:
<189>Oct 13 16:48:08 2000 10.1.1.1 10IFNET/2/210231a64jx073000020: VTY logged in from 192.168.1.21

·     cmcc format:
<189>Oct 9 14:59:04 2009 Sysname %10SHELL/5/SHELL_LOGIN: VTY logged in from 192.168.1.21

 

Table 35 describes the fields in a log message.

Table 35 Log field description

Field

Description

Prefix (information type)

A log to a destination other than the log host has an identifier in front of the timestamp:

·     An identifier of percent sign (%) indicates a log with a level equal to or higher than informational.

·     An identifier of asterisk (*) indicates a debug log or a trace log.

·     An identifier of caret (^) indicates a diagnostic log.

PRI (priority)

A log destined to the log host has a priority identifier in front of the timestamp. The priority is calculated by using this formula: facility*8+level, where:

·     facility is the facility name. Facility names local0 through local7 correspond to values 16 through 23. The facility name can be configured using the info-center loghost command. It is used to identify log sources on the log host, and to query and filter the logs from specific log sources.

·     level is in the range of 0 to 7. See Table 27 for more information about severity levels.

Timestamp

Records the time when the log was generated.

Logs sent to the log host and those sent to the other destinations have different timestamp precisions, and their timestamp formats are configured with different commands. For more information, see Table 36 and Table 37.

Hostip

Source IP address of the log. If the info-center loghost source command is configured, this field displays the IP address of the specified source interface. Otherwise, this field displays the sysname.

This field exists only in logs in unicom format that are sent to the log host.

Serial number

Serial number of the device that generated the log.

This field exists only in logs in unicom format that are sent to the log host.

Sysname (host name or host IP address)

The sysname is the host name or IP address of the device that generated the log. You can use the sysname command to modify the name of the device.

%% (vendor ID)

Indicates that the information was generated by an H3C device.

This field exists only in logs sent to the log host.

vv (version information)

Identifies the version of the log, and has a value of 10.

This field exists only in logs that are sent to the log host.

Module

Specifies the name of the module that generated the log. You can enter the info-center source ? command in system view to view the module list.

Level

Identifies the level of the log. See Table 27 for more information about severity levels.

Mnemonic

Describes the content of the log. It contains a string of up to 32 characters.

Source

Identifies the source of the log. It can take one of the following values:

·     IRF member ID.

·     IP address of the log sender.

Content

Provides the content of the log.

 

Table 36 Timestamp precisions and configuration commands

Item

Destined to the log host

Destined to the console, monitor terminal, log buffer, and log file

Precision

Seconds

Milliseconds

Command used to set the timestamp format

info-center timestamp loghost

info-center timestamp

 

Table 37 Description of the timestamp parameters

Timestamp parameters

Description

Example

boot

Time that has elapsed since system startup, in the format of xxx.yyy. xxx represents the higher 32 bits, and yyy represents the lower 32 bits, of milliseconds elapsed.

Logs that are sent to all destinations other than a log host support this parameter.

%0.109391473 Sysname FTPD/5/FTPD_LOGIN: User ftp (192.168.1.23) has logged in successfully.

0.109391473 is a timestamp in the boot format.

date

Current date and time, in the format of mmm dd hh:mm:ss yyy for logs that are output to a log host, or MMM DD hh:mm:ss:xxx YYYY for logs that are output to other destinations.

All logs support this parameter.

%May 30 05:36:29:579 2003 Sysname FTPD/5/FTPD_LOGIN: User ftp (192.168.1.23) has logged in successfully.

May 30 05:36:29:579 2003 is a timestamp in the date format.

iso

Timestamp format stipulated in ISO 8601.

Only logs that are sent to a log host support this parameter.

<189>2003-05-30T06:42:44 Sysname %%10FTPD/5/FTPD_LOGIN(l): User ftp (192.168.1.23) has logged in successfully.

2003-05-30T06:42:44 is a timestamp in the iso format.

none

No timestamp is included.

All logs support this parameter.

% Sysname FTPD/5/FTPD_LOGIN: User ftp (192.168.1.23) has logged in successfully.

No timestamp is included.

no-year-date

Current date and time without year information, in the format of MMM DD hh:mm:ss:xxx.

Only logs that are sent to a log host support this parameter.

<189>May 30 06:44:22 Sysname %%10FTPD/5/FTPD_LOGIN(l): User ftp (192.168.1.23) has logged in successfully.

May 30 06:44:22 is a timestamp in the no-year-date format.

 

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

Information center configuration task list

Task at a glance

Perform at least one of the following tasks:

·     Outputting logs to the console

·     Outputting logs to the monitor terminal

·     Outputting logs to log hosts

·     Outputting logs to the log buffer

·     Saving logs to the log file

(Optional.) Saving security logs to the security log file

(Optional.) Saving diagnostic logs to the diagnostic log file

(Optional.) Setting the minimum storage period for logs

(Optional.) Enabling synchronous information output

(Optional.) Enabling duplicate log suppression

(Optional.) Disabling an interface from generating link up or link down logs

(Optional.) Enabling SNMP notifications for system logs

 

Outputting logs to the console

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable the information center.

info-center enable

By default, the information center is enabled.

3.     Configure an output rule for the console.

info-center source { module-name | default } { console | monitor | logbuffer | logfile | loghost } { deny | level severity }

For information about default output rules, see "Default output rules for logs."

4.     (Optional.) Configure the timestamp format.

info-center timestamp { boot | date | none }

By default, the timestamp format is date.

5.     Return to user view.

quit

N/A

6.     (Optional.) Enable log output to the console.

terminal monitor

The default setting is enabled.

7.     Enable the display of debug information on the current terminal.

terminal debugging

By default, the display of debug information is disabled on the current terminal.

8.     (Optional.) Set the lowest severity level of logs that can be output to the console.

terminal logging level severity

The default setting is 6 (informational).

 

Outputting logs to the monitor terminal

Monitor terminals refer to terminals that log in to the device through the AUX, VTY, or TTY line.

To output logs to the monitor terminal:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable the information center.

info-center enable

By default, the information center is enabled.

3.     Configure an output rule for the monitor terminal.

info-center source { module-name | default } { console | monitor | logbuffer | logfile | loghost } { deny | level severity }

For information about default output rules, see "Default output rules for logs."

4.     (Optional.) Configure the timestamp format.

info-center timestamp { boot | date | none }

The default timestamp format is date.

5.     Return to user view.

quit

N/A

6.     Enable log output to the monitor terminal.

terminal monitor

By default, log output to the monitor terminal is enabled.

7.     Enable the display of debug information on the current terminal.

terminal debugging

By default, the display of debug information is disabled on the current terminal.

8.     (Optional.) Set the lowest level of logs that can be output to the monitor terminal.

terminal logging level severity

The default setting is 6 (informational).

 

Outputting logs to log hosts

Outputting common logs to log hosts

All the logging-enabled service modules send logs to the device information center. The information center outputs the logs to appropriate destinations (console, terminal monitor, log buffer, log host, and log file), depending on the log output configuration. One log can be output to multiple destinations. Logs destined for the same destination are queued and output in the order they arrive at the information center.

To output common logs to log hosts:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable the information center.

info-center enable

By default, the information center is enabled.

3.     Configure an output rule for the log host.

info-center source { module-name | default } { console | monitor | logbuffer | logfile | loghost } { deny | level severity }

For information about default output rules, see "Default output rules for logs."

4.     (Optional.) Specify the source IP address for output logs.

info-center loghost source interface-type interface-number

By default, the source IP address of output log information is the primary IP address of the matching route's egress interface.

5.     (Optional.) Specify the format for logs to be output to log hosts.

info-center format { unicom |cmcc }

By default, logs are output to log hosts in standard format.

6.     (Optional.) Configure the timestamp format.

info-center timestamp loghost { date | iso | no-year-date | none }

The default timestamp format is date.

7.     Specify a log host and configure related parameters.

info-center loghost { hostname | ipv4-address | ipv6 ipv6-address } [ port port-number ] [ facility local-number ]

By default, no log hosts or related parameters are specified.

The value for the port-number argument must be the same as the value configured on the log host. Otherwise, the log host cannot receive logs.

 

Outputting custom logs to log hosts

The following matrix shows the feature and hardware compatibility:

 

Hardware series

Model

Feature compatibility

WX1800H series

WX1804H

WX1810H

WX1820H

WX1840H

No

WX3800H series

WX3820H

WX3840H

Yes

WX5800H series

WX5860H

Yes

 

The custom log output feature enables fast delivery of logs. Logs that are sent as custom logs are not sent to the information center. Instead, they are sent directly to the log hosts specified by using the customlog host command.

The custom log output feature is available for the attack defense, NAT, packet filter, and session modules. See related documents for information about these modules.

To output custom NAT logs to a log host, you must specify the log format required by the log host in the customlog format and customlog host commands.

Logs of the attack defense, packet filter, and session modules can be output as custom logs only in H3C format.

To output custom logs to log hosts:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable custom log output.

customlog format { attack-defense | nat { cmcc | telecom | unicom } | packet-filter | session }

By default, custom log output is disabled.

3.     Specify a log host for custom logs and configure related parameters.

customlog host { hostname | ipv4-address | ipv6 ipv6-address } [ port port-number ] export { attack-defense | cmcc-sessionlog | cmcc-userlog | packet-filter | session | telecom-sessionlog | telecom-userlog | unicom-sessionlog | unicom-userlog } *

By default, no log hosts are specified for custom logs.

The value for the port-number argument must be the same as the value configured on the log host. Otherwise, the log host cannot receive custom logs.

4.     (Optional.) Specify the source IP address for output custom logs.

customlog host source interface-type interface-number

By default, the source IP address of output custom logs is the primary IP address of the outgoing interface.

5.     (Optional.) Configure the timestamp of output custom logs to show the local time.

customlog timestamp localtime

By default, the timestamp of output custom logs shows the Greenwich Mean Time (GMT).

 

Outputting logs to the log buffer

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable the information center.

info-center enable

By default, the information center is enabled.

3.     Enable log output to the log buffer.

info-center logbuffer

By default, log output to the log buffer is enabled.

4.     (Optional.) Set the maximum number of logs that can be stored in the log buffer.

info-center logbuffer size buffersize

By default, the log buffer can store 512 logs.

5.     Configure an output rule for the log buffer.

info-center source { module-name | default } { console | monitor | logbuffer | logfile | loghost } { deny | level severity }

For information about default output rules, see "Default output rules for logs."

6.     (Optional.) Configure the timestamp format.

info-center timestamp { boot | date | none }

The default timestamp format is date.

 

Saving logs to the log file

Before logs are saved to a log file, they are output to a temporary buffer called the log file buffer. The log file buffer and the log buffer are different log output destinations.

By default, the log file feature saves logs from the log file buffer to a log file every 24 hours. You can adjust the saving interval or manually save logs to a log file. After saving logs to a log file, the system clears the log file buffer.

The device supports only one log file. The log file has a maximum capacity. When the maximum capacity is reached, the system replaces the oldest logs with new logs.

To save logs to a log file:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable the information center.

info-center enable

By default, the information center is enabled.

3.     Enable the log file feature.

info-center logfile enable

By default, the log file feature is enabled.

4.     (Optional.) Set the maximum size for a log file.

info-center logfile size-quota size

The default setting varies by device model. For more information, see Network Management and Monitoring Command Reference.

To ensure normal operation, set the size argument to a value between 1 MB and 10 MB.

5.     (Optional.) Specify the directory to save a log file.

info-center logfile directory dir-name

By default, the log file is saved in the logfile directory under the root directory of the storage device.

This command cannot survive a reboot. (IRF-incapable devices.)

This command cannot survive an IRF reboot or a master/subordinate switchover. (IRF-capable devices.)

6.     Save the logs in the log file buffer to a log file.

·     Configure the interval to perform the save operation:
info-center logfile frequency
freq-sec

·     Manually save the logs in the log file buffer to a log file:
logfile save

The default log file saving interval is 86400 seconds.

The logfile save command is available in any view.

 

Saving security logs to the security log file

Security logs are very important for locating and troubleshooting network problems. Generally, security logs are output together with other logs. It is difficult to identify security logs among all logs.

To solve this problem, you can save security logs to the security log file without affecting the current log output rules.

After you enable the saving of the security logs to the security log file:

·     The system first outputs security logs to the security log file buffer.

·     The system saves the logs from the security log file buffer to the security log file at intervals (the security log administrator can also manually save security logs to the security log file).

·     After the security logs are saved, the buffer is cleared immediately.

The device supports only one security log file. To avoid security log loss, you can set an alarm threshold for the security log file usage. When the alarm threshold is reached, the system outputs a message to inform the administrator. The administrator can log in to the device as the security log administrator and back up the security log file to prevent the loss of important data.

To save security logs to the security log file:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable the information center.

info-center enable

By default, the information center is enabled.

3.     Enable the saving of the security logs to the security log file.

info-center security-logfile enable

By default, saving security logs to the security log file is disabled.

4.     Set the interval at which the system saves security logs.

info-center security-logfile frequency freq-sec

By default, the security log file saving interval is 86400 seconds.

5.     (Optional.) Set the maximum size for the security log file.

info-center security-logfile size-quota size

By default, the maximum size for the security log file is 10 MB.

6.     (Optional.) Set the alarm threshold of the security log file usage.

info-center security-logfile alarm-threshold usage

By default, the alarm threshold of the security log file usage is 80. When the usage of the security log file reaches 80%, the system will inform the user.

 

Saving diagnostic logs to the diagnostic log file

By default, the device saves diagnostic logs from the diagnostic log file buffer to the diagnostic log file every 24 hours. You can adjust the saving interval or manually save diagnostic logs to the diagnostic log file. After saving diagnostic logs to the diagnostic log file, the system clears the diagnostic log file buffer.

The device supports only one diagnostic log file. The diagnostic log file has a maximum capacity. When the capacity is reached, the system replaces the oldest diagnostic logs with new logs.

To enable saving diagnostic logs to the diagnostic log file:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable the information center.

info-center enable

By default, the information center is enabled.

3.     Enable saving diagnostic logs to the diagnostic log file.

info-center diagnostic-logfile enable

By default, saving diagnostic logs to the diagnostic log file is enabled.

4.     (Optional.) Set the maximum size for the diagnostic log file.

info-center diagnostic-logfile quota size

By default, the maximum size for the diagnostic log file is 10 MB.

To ensure normal operation, set the size argument to a value between 1 MB and 10 MB.

5.     (Optional.) Specify the directory to save the diagnostic log file.

info-center diagnostic-logfile directory dir-name

By default, the diagnostic log file is saved in the diagfile directory under the root directory of the storage device.

This command cannot survive a reboot. (IRF-incapable devices.)

This command cannot survive an IRF reboot or a master/subordinate switchover. (IRF-capable devices.)

6.     Save diagnostic logs in the diagnostic log file buffer to the diagnostic log file.

·     Configure the interval to perform the saving operation:
info-center diagnostic-logfile frequency
freq-sec

·     Manually save diagnostic logs in the buffer to the diagnostic log file:
diagnostic-logfile save

The default diagnostic log file saving interval is 86400 seconds

The diagnostic-logfile save command is available in any view.

 

Setting the minimum storage period for logs

Use this feature to set the minimum storage period for logs in the log buffer and log file. This feature ensures that logs will not be overwritten by new logs in a specific period of time.

By default, when the log buffer or log file is full, new logs will automatically overwrite the oldest logs. After the minimum storage period is set, the system identifies the storage period of a log to determine whether to delete the log. The system current time minus a log's generation time is the log's storage period.

·     If the storage period of a log is shorter than or equal to the minimum storage period, the system does not delete the log. The new log will not be saved.

·     If the storage period of a log is longer than the minimum storage period, the system deletes the log to save the new log.

To set the log minimum storage period:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Set the log minimum storage period.

info-center syslog min-age min-age

By default, the log minimum storage period is not set.

 

Enabling synchronous information output

System log output interrupts ongoing configuration operations, obscuring previously entered commands. Synchronous information output shows the obscured commands. It also provides a command prompt in command editing mode, or a [Y/N] string in interaction mode so you can continue your operation from where you were stopped.

To enable synchronous information output:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable synchronous information output.

info-center synchronous

By default, synchronous information output is disabled.

 

Enabling duplicate log suppression

The output of consecutive duplicate logs at an interval of less than 30 seconds wastes system and network resources.

With this feature enabled, the system starts a suppression period upon outputting a log:

·     During the suppression period, the system does not output logs that have the same module name, level, mnemonic, location, and text as the previous log.

·     After the suppression period expires, if the same log continues to appear, the system outputs the suppressed logs and the log number and starts another suppression period. The suppression period is 30 seconds for the first time, 2 minutes for the second time, and 10 minutes for subsequent times.

·     If a different log is generated during the suppression period, the system aborts the current suppression period, outputs suppressed logs and the log number and then the different log, and starts another suppression period.

To enable duplicate log suppression:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable duplicate log suppression.

info-center logging suppress duplicates

By default, duplicate log suppression is disabled.

 

Disabling an interface from generating link up or link down logs

By default, all interfaces generate link up or link down log information when the interface state changes. In some cases, you might want to disable certain interfaces from generating this information. For example:

·     You are concerned only about the states of some interfaces. In this case, you can use this function to disable other interfaces from generating link up and link down log information.

·     An interface is unstable and continuously outputs log information. In this case, you can disable the interface from generating link up and link down log information.

Use the default setting in normal cases to avoid affecting interface status monitoring.

To disable an interface from generating link up or link down logs:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Disable the interface from generating link up or link down logs.

undo enable log updown

By default, all interfaces generate link up and link down logs when the interface state changes.

 

Enabling SNMP notifications for system logs

This feature enables the device to send an SNMP notification for each log message it outputs. The device encapsulates the logs in SNMP notifications and then sends them to the SNMP module and the log trap buffer.

You can configure the SNMP module to send received SNMP notifications in SNMP traps or informs to remote hosts. For more information, see "Configuring SNMP."

To view the traps in the log trap buffer, access the MIB corresponding to the log trap buffer.

To enable SNMP notifications for system logs:

 

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enable SNMP notifications for system logs.

snmp-agent trap enable syslog

N/A

3.     Set the maximum number of traps that can be stored in the log trap buffer.

info-center syslog trap buffersize buffersize

By default, the log trap buffer can store a maximum of 1024 traps.

 

Displaying and maintaining information center

Execute display commands in any view and reset commands in user view.

 

Task

Command

Display the information of each output destination.

display info-center

Display the state and the log information of the log buffer.

display logbuffer [ reverse ] [ level severity | size buffersize | slot slot-number ]*

Display a summary of the log buffer.

display logbuffer summary [ level severity | slot slot-number ] *

Display the log file configuration.

display logfile summary

Display the diagnostic log file configuration.

display diagnostic-logfile summary

Clear the log buffer.

reset logbuffer

 

Information center configuration examples

Configuration example for outputting logs to the console

Network requirements

Configure the device to output to the console FTP logs that have a severity level of at least warning.

Figure 53 Network diagram

 

Configuration procedure

# Enable the information center.

<AC> system-view

[AC] info-center enable

# Disable log output to the console.

[AC] info-center source default console deny

To avoid output of unnecessary information, disable all modules from outputting log information to the specified destination (console in this example) before you configure the output rule.

# Configure an output rule to output to the console FTP logs that have a severity level of at least warning.

[AC] info-center source ftp console level warning

[AC] quit

# Enable the display of logs on the console. (This function is enabled by default.)

<AC> terminal logging level 6

<AC> terminal monitor

The current terminal is enabled to display logs.

Now, if the FTP module generates logs, the information center automatically sends the logs to the console, and the console displays the logs.

Configuration example for outputting logs to a UNIX log host

Network requirements

Configure the AC to output to the UNIX log host FTP logs that have a severity level of at least informational.

Figure 54 Network diagram

 

Configuration procedure

Before the configuration, make sure the AC and the log host can reach each other. (Details not shown.)

1.     Configure the AC:

# Enable the information center.

<AC> system-view

[AC] info-center enable

# Specify the log host 1.2.0.1/16 and specify local4 as the logging facility.

[AC] info-center loghost 1.2.0.1 facility local4

# Disable log output to the log host.

[AC] info-center source default loghost deny

To avoid output of unnecessary information, disable all modules from outputting logs to the specified destination (loghost in this example) before you configure an output rule.

# Configure an output rule to output to the log host FTP logs that have a severity level of at least informational.

[AC] info-center source ftp loghost level informational

2.     Configure the log host:

The following configurations were performed on Solaris. Other UNIX operating systems have similar configurations.

a.     Log in to the log host as a root user.

b.     Create a subdirectory named AC in directory /var/log/, and then create file info.log in the AC directory to save logs from AC.

# mkdir /var/log/AC

# touch /var/log/AC/info.log

c.     Edit the file syslog.conf in directory /etc/ and add the following contents.

# AC configuration messages

local4.info /var/log/AC/info.log

In this configuration, local4 is the name of the logging facility that the log host uses to receive logs. info is the informational level. The UNIX system records the log information that has a severity level of at least informational to the file /var/log/AC/info.log.

 

 

NOTE:

Follow these guidelines while editing the file /etc/syslog.conf:

·     Comments must be on a separate line and must begin with a pound sign (#).

·     No redundant spaces are allowed after the file name.

·     The logging facility name and the severity level specified in the /etc/syslog.conf file must be identical to those configured on the AC by using the info-center loghost and info-center source commands. Otherwise, the log information might not be output properly to the log host.

 

d.     Display the process ID of syslogd, kill the syslogd process, and then restart syslogd using the –r option to make the new configuration take effect.

# ps -ae | grep syslogd

147

# kill -HUP 147

# syslogd -r &

Now, the AC can output FTP logs to the log host, which stores the logs to the specified file.

Configuration example for outputting logs to a Linux log host

Network requirements

Configure the AC to output to the Linux log host 1.2.0.1/16 FTP logs that have a severity level of at least informational.

Figure 55 Network diagram

 

Configuration procedure

Before the configuration, make sure the AC and the log host can reach each other. (Details not shown.)

1.     Configure the AC:

# Enable the information center.

<AC> system-view

[AC] info-center enable

# Specify the log host 1.2.0.1/16, and specify local5 as the logging facility.

[AC] info-center loghost 1.2.0.1 facility local5

# Disable log output to the log host.

[AC] info-center source default loghost deny

To avoid outputting unnecessary information, disable all modules from outputting log information to the specified destination (loghost in this example) before you configure an output rule.

# Configure an output rule to enable output to the log host FTP logs that have a severity level of at least informational.

[AC] info-center source ftp loghost level informational

2.     Configure the log host:

The following configurations were performed on Solaris. Other UNIX operating systems have similar configurations.

a.     Log in to the log host as a root user.

b.     Create a subdirectory named AC in the directory /var/log/, and create file info.log in the AC directory to save logs of AC.

# mkdir /var/log/AC

# touch /var/log/AC/info.log

c.     Edit the file syslog.conf in directory /etc/ and add the following contents.

# AC configuration messages

local5.info /var/log/AC/info.log

In the above configuration, local5 is the name of the logging facility used by the log host to receive logs. info is the informational level. The Linux system will store the log information with a severity level equal to or higher than informational to the file /var/log/AC/info.log.

 

 

NOTE:

Follow these guidelines while editing the file /etc/syslog.conf:

·     Comments must be on a separate line and must begin with a pound sign (#).

·     No redundant spaces are allowed after the file name.

·     The logging facility name and the severity level specified in the /etc/syslog.conf file must be identical to those configured on the AC by using the info-center loghost and info-center source commands. Otherwise, the log information might not be output properly to the log host.

 

d.     Display the process ID of syslogd, kill the syslogd process, and then restart syslogd by using the -r option to apply the new configuration.

Make sure the syslogd process is started with the -r option on a Linux log host.

# ps -ae | grep syslogd

147

# kill -9 147

# syslogd -r &

Now, the system can record log information to the specified file.

 


Configuring port mirroring

Overview

Port mirroring copies the packets passing through a port to a port that connects to a data monitoring device for packet analysis.

Terminology

The following terms are used in port mirroring configuration.

Mirroring source

The mirroring sources can be one or more monitored ports called source ports.

Packets passing through mirroring sources are copied to a port connecting to a data monitoring device for packet analysis. The copies are called mirrored packets.

Source device

The device where the mirroring sources reside is called a source device.

Mirroring destination

The mirroring destination connects to a data monitoring device and is the destination port (also known as the monitor port) of mirrored packets. Mirrored packets are sent out of the monitor port to the data monitoring device.

A monitor port might receive multiple copies of a packet when it monitors multiple mirroring sources. For example, two copies of a packet are received on Port 1 when the following conditions exist:

·     Port 1 is monitoring bidirectional traffic of Port 2 and Port 3 on the same device.

·     The packet travels from Port 2 to Port 3.

Destination device

The device where the monitor port resides is called the destination device.

Mirroring direction

The mirroring direction specifies the direction of the traffic that is copied on a mirroring source.

·     Inbound—Copies packets received.

·     Outbound—Copies packets sent.

·     Bidirectional—Copies packets received and sent.

Mirroring group

Port mirroring is implemented through mirroring groups. The device supports only local mirroring groups. For more information about local mirroring groups, see "Local port mirroring implementation."

On port mirroring-enabled devices, all ports except the source ports and the destination port are called common ports.

Local port mirroring implementation

In local port mirroring, the following conditions exist:

·     The source device is directly connected to a data monitoring device.

·     The source device acts as the destination device to forward mirrored packets to the data monitoring device.

A local mirroring group is a mirroring group that contains the mirroring sources and the mirroring destination on the same device.

 

 

NOTE:

The local mirroring group does not support multicard or multichassis mirroring.

 

Figure 56 Local port mirroring implementation

 

As shown in Figure 56, the source port GigabitEthernet 1/0/1 and the monitor port GigabitEthernet 1/0/2 reside on the same device. Packets received on GigabitEthernet 1/0/1 are copied to GigabitEthernet 1/0/2. GigabitEthernet 1/0/2 then forwards the packets to the data monitoring device for analysis.

Local port mirroring configuration task list

A local mirroring group takes effect only after you configure the monitor port and the source ports for it.

 

Tasks at a glance

1.     (Required.) Creating a local mirroring group

2.     (Required.) Configuring source ports for the local mirroring group

3.     (Required.) Configuring the monitor port for the local mirroring group

 

Creating a local mirroring group

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Create a local mirroring group.

mirroring-group group-id local

By default, no local mirroring groups exist.

 

Configuring source ports for the local mirroring group

To configure source ports for a local mirroring group, use one of the following methods:

·     Assign a list of source ports to the mirroring group in system view.

·     Assign a port to the mirroring group as a source port in interface view.

To assign multiple ports to the mirroring group as source ports in interface view, repeat the operation.

Configuration restrictions and guidelines

When you configure source ports for a local mirroring group, follow these restrictions and guidelines:

·     A Layer 2 aggregate interface cannot be configured as a source port for a mirroring group.

·     A mirroring group can contain multiple source ports.

·     A port can act as a source port for only one mirroring group.

·     A source port cannot be configured as a monitor port.

Configuring source ports in system view

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure source ports for a local mirroring group.

mirroring-group group-id mirroring-port interface-list { both | inbound | outbound }

By default, no source port is configured for a local mirroring group.

 

Configuring source ports in interface view

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Configure the port as a source port for a local mirroring group.

mirroring-group group-id mirroring-port { both | inbound | outbound }

By default, a port does not act as a source port for any local mirroring groups.

 

Configuring the monitor port for the local mirroring group

To configure the monitor port for a mirroring group, use one of the following methods:

·     Configure the monitor port for the mirroring group in system view.

·     Assign a port to the mirroring group as the monitor port in interface view.

Configuration restrictions and guidelines

When you configure the monitor port for a local mirroring group, follow these restrictions and guidelines:

·     Do not enable the spanning tree feature on the monitor port.

·     For a Layer 2 aggregate interface configured as the monitor port of a mirroring group, do not configure its member ports as source ports of the mirroring group.

·     Use a monitor port only for port mirroring, so the data monitoring device receives only the mirrored traffic.

Configuring the monitor port in system view

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Configure the monitor port for a local mirroring group.

mirroring-group group-id monitor-port interface-list

By default, no monitor port is configured for a local mirroring group.

 

Configuring the monitor port in interface view

Step

Command

Remarks

1.     Enter system view.

system-view

N/A

2.     Enter interface view.

interface interface-type interface-number

N/A

3.     Configure the port as the monitor port for a mirroring group.

mirroring-group group-id monitor-port

By default, a port does not act as the monitor port for any local mirroring groups.

 

Displaying and maintaining port mirroring

Execute display commands in any view.

 

Task

Command

Display mirroring group information.

display mirroring-group { group-id | all | local }

 

Local port mirroring configuration example

Network requirements

As shown in Figure 57, configure local port mirroring on the AC to enable the server to monitor the bidirectional traffic of the IP network.

Figure 57 Network diagram

 

Configuration procedure

# Create local mirroring group 1.

<AC> system-view

[AC] mirroring-group 1 local

# Configure local mirroring group 1 to monitor the bidirectional traffic of GigabitEthernet 1/0/1.

[AC] mirroring-group 1 mirroring-port gigabitethernet 1/0/1 both

# Configure GigabitEthernet 1/0/2 as the monitor port for local mirroring group 1.

[AC] mirroring-group 1 monitor-port gigabitethernet 1/0/2

Verifying the configuration

# Verify the mirroring group configuration.

[AC] display mirroring-group 1

Mirroring group 1:

    Type: Local

    Status: Active

    Mirroring port:

        GigabitEthernet1/0/1  both

    Monitor port: GigabitEthernet1/0/2

 



A

access control

NTP access control rights, 66

NTP security, 61

accessing

NTP access control, 61

SNMP access control mode, 88

SNMP MIB access control, 87

SNMP view-based MIB access control, 87

address

ping address reachability determination, 1

agent

SNMP agent host notification, 95

alarm

RMON alarm function, 104

RMON alarm function configuration, 108

RMON alarm group sample type, 103

RMON configuration, 101, 105

RMON group, 102

RMON private group, 102

AP

local packet capture for AP radio configuration, 195

remote packet capture for AP radio configuration, 195

applying

PoE profile, 175

PoE profile (multiple PIs in system view), 175

PoE profile (single PI in PI view), 175

architecture

NTP, 58

arithmetic

capture filter operator, 189

arithmetic operator

capture filter, 187

associating

IPv6 NTP client/server association mode, 77

IPv6 NTP symmetric active/passive association mode, 79

NTP association mode, 63

NTP broadcast association mode, 59, 65

NTP client/server association mode, 59, 63, 76

NTP client/server association mode with authentication, 81

NTP multicast association mode, 59, 65

NTP symmetric active/passive association mode, 59, 64, 78

authenticating

NTP, 61

NTP broadcast authentication, 70

NTP client/server mode authentication, 67

NTP client/server mode with authentication, 81

NTP configuration, 67

NTP multicast authentication, 71

NTP security, 61

NTP symmetric active/passive mode authentication, 69

SNTP authentication, 84

B

bidirectional

port mirroring, 217

broadcast

NTP broadcast association mode, 59, 65, 70

NTP broadcast client configuration, 65

NTP broadcast mode dynamic associations max, 74

NTP broadcast server configuration, 65

buffer

information center log buffer, 207

C

capturing

packet configuration, 187

changing

NETCONF parameter value, 127

CLI

EAA configuration, 154, 162

EAA monitor policy configuration, 158, 162

EAA monitor policy configuration (CLI+environment variables), 163

NETCONF CLI operations, 140, 140

NETCONF return to CLI, 144

client

NQA client history record save, 22

NQA client operation (FTP), 12

NQA client operation (HTTP), 13

NQA client operation (ICMP echo), 10

NQA client operation (ICMP jitter), 11

NQA client operation (SNMP), 16

NQA client operation (TCP), 16

NQA client operation (UDP echo), 17

NQA client operation (UDP jitter), 14

NQA client operation scheduling, 23

NQA client statistics collection, 21

NQA client template, 23

NQA client template (FTP), 30

NQA client template (HTTP), 27

NQA client template (HTTPS), 28

NQA client template (ICMP), 24

NQA client template (RADIUS), 31

NQA client template (SSL), 31

NQA client template (TCP half open), 25

NQA client template (TCP), 25

NQA client template (UDP), 26

NQA client template optional parameters, 32

NQA client threshold monitoring, 8, 19

NQA client+Track collaboration, 18

NQA collaboration configuration (on switch), 46

NQA echo operation configuration (ICMP), 34

NQA enable, 9

NQA FTP operation configuration, 38

NQA HTTP operation configuration, 39

NQA operation, 10

NQA operation configuration (ICMP jitter), 35

NQA SNMP operation configuration, 43

NQA TCP operation configuration, 44

NQA UDP echo operation configuration, 45

NQA UDP jitter operation configuration, 40

NTP broadcast client configuration, 65

NTP multicast client configuration, 65

SNTP configuration, 83, 85

client/server

IPv6 NTP client/server association mode, 77

NTP association mode, 59, 63

NTP client/server association mode, 67, 76

NTP client/server association mode with authentication, 81

NTP client/server mode dynamic associations max, 74

clock

NTP local clock as reference source, 75

collaborating

NQA client+Track function, 18

NQA+Track collaboration, 8

command and hardware compatibility

information center, 204

PMM, 166

common

information center common logs, 199

comparison

capture filter operator, 189

display filter expression, 194

display filter operator, 192

comparison operator

capture filter, 187

conditional match

NETCONF data filtering, 139

NETCONF data filtering (column-based), 136

configuring

EAA, 154, 162

EAA environment variable (user-defined), 157

EAA monitor policy, 158

EAA monitor policy (CLI), 158, 162

EAA monitor policy (CLI+environment variables), 163

EAA monitor policy (Tcl), 160, 164

flow log, 178, 179, 183

flow log export to flow log host group, 185

flow log host group, 182

flow log host group (IPv4), 183

flow log host group (IPv6), 183

flow log timestamp, 181

flow log version, 181

information center, 199, 204, 213

IPv6 NTP client/server association mode, 77

IPv6 NTP symmetric active/passive association mode, 79

local packet capture, 196, 196

local packet capture for AP radio, 195

local port mirroring, 221

local port mirroring group monitor port, 219

local port mirroring group monitor port (interface view), 220

local port mirroring group monitor port (system view), 220

local port mirroring group source ports, 219

local port mirroring group source ports (interface view), 219

local port mirroring group source ports (system view), 219

NETCONF, 110, 113

NETCONF over SOAP, 113

NQA, 7, 9, 34

NQA client history record save, 22

NQA client operation, 10

NQA client operation (FTP), 12

NQA client operation (HTTP), 13

NQA client operation (ICMP echo), 10

NQA client operation (ICMP jitter), 11

NQA client operation (SNMP), 16

NQA client operation (TCP), 16

NQA client operation (UDP echo), 17

NQA client operation (UDP jitter), 14

NQA client operation optional parameters, 18

NQA client statistics collection, 21

NQA client template, 23

NQA client template (FTP), 30

NQA client template (HTTP), 27

NQA client template (HTTPS), 28

NQA client template (ICMP), 24

NQA client template (RADIUS), 31

NQA client template (SSL), 31

NQA client template (TCP half open), 25

NQA client template (TCP), 25

NQA client template (UDP), 26

NQA client template optional parameters, 32

NQA client threshold monitoring, 19

NQA client+Track collaboration, 18

NQA collaboration (on switch), 46

NQA echo operation (ICMP), 34

NQA FTP operation, 38

NQA FTP template, 53

NQA HTTP operation, 39

NQA HTTP template, 52

NQA ICMP template, 49

NQA operation (ICMP jitter), 35

NQA RADIUS template, 54

NQA server, 9

NQA SNMP operation, 43

NQA TCP operation, 44

NQA TCP template configuration, 50

NQA template (HTTPS), 53

NQA template (SSL), 55

NQA template (TCP half open), 50

NQA UDP echo operation, 45

NQA UDP jitter operation, 40

NQA UDP template configuration, 51

NTP, 57, 62, 76

NTP access control rights, 66

NTP association mode, 63

NTP authentication, 67

NTP broadcast association mode, 65

NTP broadcast client, 65

NTP broadcast mode authentication, 70

NTP broadcast server, 65

NTP client/server association mode, 63, 76

NTP client/server mode authentication, 67

NTP client/server mode with authentication, 81

NTP dynamic associations max, 74

NTP local clock as reference source, 75

NTP multicast association mode, 65

NTP multicast client, 65

NTP multicast mode authentication, 71

NTP multicast server, 66

NTP optional parameters, 73

NTP packet DSCP value, 75

NTP symmetric active/passive association mode, 64, 78

NTP symmetric active/passive mode authentication, 69

packet capture, 187, 194, 196

PMM kernel thread deadloop detection, 167

PMM kernel thread starvation detection, 168

PoE, 170, 171, 176

PoE monitoring, 173

PoE PI power max, 172

PoE PI priority policy, 173

PoE profile PI, 174

remote packet capture, 197, 197

remote packet capture for AP radio, 195

RMON, 101, 105

RMON alarm function, 104, 108

RMON Ethernet statistics group, 105

RMON history group, 106

RMON statistics function, 103

SNMP, 87

SNMP agent host notification, 95

SNMP basics, 89

SNMP logging, 93

SNMP notification, 94

SNMPv1, 97

SNMPv1 agent host notification, 95

SNMPv1 basics, 89

SNMPv2c, 97

SNMPv2c agent host notification, 95

SNMPv2c basics, 89

SNMPv3, 98

SNMPv3 agent host notification, 95

SNMPv3 basics, 91

SNTP, 83, 85

SNTP authentication, 84

console

information center log output, 204, 213

constant

capture filter keyword, 188

controlling

NTP access control rights, 66

RMON history control entry, 103

creating

local port mirroring group, 218

RMON Ethernet statistics entry, 103

RMON history control entry, 103

custom

information center custom logs, 199

D

data

NETCONF configuration data retrieval (all modules), 123

NETCONF configuration data retrieval (Syslog module), 125

NETCONF data entry retrieval (interface table), 126

NETCONF filtering (conditional match), 139

NETCONF filtering (regex match), 137

NMM NETCONF filtering (column-based), 135

NMM NETCONF filtering (column-based) (conditional match), 136

NMM NETCONF filtering (column-based) (full match), 135

NMM NETCONF filtering (column-based) (regex match), 136

NMM NETCONF filtering (table-based), 134

deadloop detection (Linux kernel PMM), 167

debugging

feature module, 6

system, 5

system maintenance, 1

default

information center log default output rules, 200

system information custom log output rules, 201

system information diagnostic log output rules, 200

system information hidden log output rules, 201

system information security log output rules, 201

system information trace log output rules, 201

destination

information center system logs, 200

port mirroring, 217

port mirroring destination device, 217

detecting

PMM kernel thread deadloop detection, 167

PMM kernel thread starvation detection, 168

PoE PD detection (nonstandard), 172

determining

ping address reachability, 1

device

information center configuration, 199, 204

information center system log types, 199

local port mirroring, 221

local port mirroring group monitor port, 219

NETCONF capability exchange, 115

NETCONF CLI operations, 140, 140

NETCONF configuration, 110, 113

NETCONF configuration lock/unlock, 118, 119

NETCONF edit-config operation, 122

NETCONF get/get-bulk operation, 120

NETCONF get-config/get-bulk-config operation, 122

NETCONF save-point/begin operation, 129

NETCONF save-point/commit operation, 130

NETCONF save-point/end operation, 131

NETCONF save-point/get-commit-information operation, 132

NETCONF save-point/get-commits operation, 131

NETCONF save-point/rollback operation, 130

NETCONF service operations, 120

NETCONF session information retrieval, 142

NETCONF session termination, 143

NQA client operation, 10

NQA collaboration configuration (on switch), 46

NQA server, 9

NQA UDP jitter operation configuration, 40

NTP architecture, 58

NTP configuration, 76

PoE configuration, 170, 171

PoE profile PI configuration, 174

port mirroring configuration, 217

port mirroring source device, 217

SNMP basics configuration, 89

SNMP configuration, 87

SNMP MIB, 87

SNMP notification, 94

SNMP view-based MIB access control, 87

SNMPv1 basics configuration, 89

SNMPv1 configuration, 97

SNMPv2c basics configuration, 89

SNMPv2c configuration, 97

SNMPv3 basics configuration, 91

SNMPv3 configuration, 98

diagnosing

information center diagnostic log, 199

information center diagnostic log save (log file), 210

direction

port mirroring (bidirectional), 217

port mirroring (inbound), 217

port mirroring (outbound), 217

disabling

information center interface link up/link down log generation, 212

NTP message processing, 74

display filter keyword

packet capture, 190

display filter operator

packet capture, 192

displaying

EAA settings, 161

flow log, 183

information center, 212

NMM packet capture, 196

NQA, 33

NTP, 75

PMM, 166

PMM kernel threads, 168

PoE, 175

port mirroring, 220

RMON settings, 105

SNMP settings, 96

SNTP, 85

user PMM, 166

DSCP

NTP packet value setting, 75

duplicate log suppression, 211

dynamic

NTP dynamic associations max, 74

E

EAA

configuration, 154, 162

environment variable configuration (user-defined), 157

event monitor, 154

event monitor policy action, 156

event monitor policy element, 155

event monitor policy environment variable, 156

event monitor policy runtime, 156

event monitor policy user role, 156

event source, 154

how it works, 154

monitor policy, 155

monitor policy configuration, 158

monitor policy configuration (CLI), 158, 162

monitor policy configuration (CLI+environment variables), 163

monitor policy configuration (Tcl), 160, 164

monitor policy configuration restrictions, 158

monitor policy suspension, 161

RTM, 154

settings display, 161

echo

NQA client operation (ICMP echo), 10

NQA echo operation configuration (ICMP), 34

NQA UDP echo operation configuration, 45

electricity

PoE configuration, 170, 171

Embedded Automation Architecture. Use EAA

enabling

flow log entry load balancing, 182

information center duplicate log suppression, 211

information center synchronous output, 211

NETCONF logging, 114

NETCONF over SSH, 114

NQA client, 9

NTP, 63

PoE PD detection (nonstandard), 172

PoE PI, 171

SNMP notification, 94

SNMP notifications for system logs, 212

SNTP, 83

entering

NETCONF XML view, 115

environment

EAA environment variable configuration (user-defined), 157

EAA event monitor policy environment variable, 156

establishing

NETCONF session, 114

Ethernet

PoE configuration, 170, 171

port mirroring configuration, 217

power over Ethernet. Use PoE

RMON Ethernet statistics entry, 103

RMON Ethernet statistics group configuration, 105

RMON statistics group, 101

event

EAA configuration, 154, 162

EAA environment variable configuration (user-defined), 157

EAA event monitor, 154

EAA event monitor policy element, 155

EAA event monitor policy environment variable, 156

EAA event source, 154

EAA monitor policy, 155

NETCONF event notification subscription, 116, 117

RMON event group, 101

exchanging

NETCONF capabilities, 115

exporting

flow log export destination, 180

flow log export destination (information center), 181

flow log export destination (log host), 180

F

field

display filter expression, 194

display filter keyword, 190

file

information center diagnostic log output destination, 210

information center log save (log file), 208

information center security log save (log file), 209

filtering

column-based filtering, 134

NETCONF data (conditional match), 139

NETCONF data (regex match), 137

NMM NETCONF data filtering (column-based), 135

NMM NETCONF data filtering (table-based), 134

table-based filtering, 134

FIPS compliance

SNMP, 89

flow log

configuration, 178, 179, 183

display, 183

entry load balancing, 182

export destination, 180

export destination (information center), 181

export destination (log host), 180

log host group configuration, 182

log host group configuration (IPv4), 183

log host group configuration (IPv6), 183

maintain, 183

packet source IP address configuration, 181

timestamp configuration, 181

version configuration, 181

flow log export

flow log export to flow log host group, 185

format

information center system logs, 201

NETCONF message, 111

FTP

NQA, 7

NQA client operation, 12

NQA client template, 30

NQA operation configuration, 38

NQA template configuration, 53

full match

NETCONF data filtering (column-based), 135

function

RMON alarm function, 104

RMON statistics function, 103

G

generating

information center interface link up/link down log generation, 212

get operation

NETCONF get/get-bulk, 120

NETCONF get-config/get-bulk-config, 122

SNMP, 88

SNMP logging, 93

group

local port mirroring group monitor port, 219

local port mirroring group source port, 219

port mirroring group, 217

RMON, 101

RMON alarm, 102

RMON alarm group sample type, 103

RMON Ethernet statistics, 101

RMON event, 101

RMON history, 101

RMON private alarm, 102

RMON private alarm group sample type, 103

H

hidden log (information center), 199

history

NQA client history record save, 22

RMON group, 101

RMON history control entry, 103

RMON history group configuration, 106

host

flow log export destination (log host), 180

information center custom log output (log host), 206

information center log output (log host), 206, 206

SNMP agent host notification, 95

HTTP

NETCONF over SOAP (HTTP-based), 113

NETCONF over SOAP (HTTPS-based), 113

NQA, 7

NQA client operation, 13

NQA client template, 27

NQA operation configuration, 39

NQA template configuration, 52

HTTPS

NQA client template (HTTPS), 28

NQA template configuration (HTTPS), 53

I

ICMP

NQA, 7

NQA client operation (ICMP echo), 10

NQA client operation (ICMP jitter), 11

NQA client template, 24

NQA collaboration configuration (on switch), 46

NQA echo operation configuration, 34

NQA operation configuration (ICMP jitter), 35

NQA template configuration, 49

ping command, 1

identifying

tracert node failure, 4, 4

implementing

local port mirroring, 217

inbound

port mirroring, 217

information center

command and hardware compatibility, 204

configuration, 199, 204, 213

custom log default output rules, 201

custom log output (log host), 206

diagnostic log default output rules, 200

diagnostic log save (log file), 210

display, 212

duplicate log suppression, 211

enabling SNMP notifications for system logs, 212

flow log export destination, 181

hidden log default output rules, 201

interface link up/link down log generation, 212

log default output rules, 200

log minimum storage period, 210

log output (console), 204, 213

log output (Linux log host), 215

log output (log buffer), 207

log output (log host), 206, 206

log output (monitor terminal), 205

log output (UNIX log host), 214

log save (log file), 208

maintain, 212

security log default output rules, 201

security log save (log file), 209

synchronous log output, 211

system information log types, 199

system log destinations, 200

system log formats, 201

system log levels, 199

trace log default output rules, 201

Internet

NQA configuration, 7, 9, 34

SNMP basics configuration, 89

SNMP configuration, 87

SNMP MIB, 87

SNMP notification, 94

SNMPv1 basics configuration, 89

SNMPv1 configuration, 97

SNMPv2c basics configuration, 89

SNMPv2c configuration, 97

SNMPv3 basics configuration, 91

SNMPv3 configuration, 98

IP addressing

flow log configuration, 178, 179, 183

flow log packet source IP address, 181

tracert, 3

tracert node failure identification, 4, 4

IP services

NQA client history record save, 22

NQA client operation (FTP), 12

NQA client operation (HTTP), 13

NQA client operation (ICMP echo), 10

NQA client operation (ICMP jitter), 11

NQA client operation (SNMP), 16

NQA client operation (TCP), 16

NQA client operation (UDP echo), 17

NQA client operation (UDP jitter), 14

NQA client operation optional parameters, 18

NQA client operation scheduling, 23

NQA client statistics collection, 21

NQA client template (FTP), 30

NQA client template (HTTP), 27

NQA client template (HTTPS), 28

NQA client template (ICMP), 24

NQA client template (RADIUS), 31

NQA client template (SSL), 31

NQA client template (TCP half open), 25

NQA client template (TCP), 25

NQA client template (UDP), 26

NQA client template optional parameters, 32

NQA client threshold monitoring, 19

NQA client+Track collaboration, 18

NQA collaboration configuration (on switch), 46

NQA configuration, 7, 9, 34

NQA echo operation configuration (ICMP), 34

NQA FTP operation configuration, 38

NQA FTP template configuration, 53

NQA HTTP operation configuration, 39

NQA HTTP template configuration, 52

NQA ICMP template configuration, 49

NQA operation configuration (ICMP jitter), 35

NQA RADIUS template configuration, 54

NQA SNMP operation configuration, 43

NQA TCP operation configuration, 44

NQA TCP template configuration, 50

NQA template configuration (HTTPS), 53

NQA template configuration (SSL), 55

NQA template configuration (TCP half open), 50

NQA UDP echo operation configuration, 45

NQA UDP jitter operation configuration, 40

NQA UDP template configuration, 51

IPv6

NTP client/server association mode, 77

NTP symmetric active/passive association mode, 79

K

kernel thread

displaying, 168

Linux process, 166

maintaining, 168

PMM, 167

PMM deadloop detection, 167

PMM starvation detection, 168

keyword

capture filter, 187

L

Layer 3

tracert, 3

tracert node failure identification, 4, 4

level

information center system logs, 199

link

information center interface link up/link down log generation, 212

Linux

information center log host output, 215

kernel thread, 166

PMM, 166

PMM kernel thread, 167

PMM kernel thread deadloop detection, 167

PMM kernel thread display, 168

PMM kernel thread maintain, 168

PMM kernel thread starvation detection, 168

load balancing

flow log entry load balancing, 182

loading

NETCONF configuration, 128, 133

local

local packet capture, 187

local packet capture for AP radio configuration, 195

NTP local clock as reference source, 75

port mirroring group creation, 218

port mirroring group monitor port, 219

port mirroring group source port, 219

local packet capture

configuration, 196

local port mirroring

implementation, 217

locking

NETCONF configuration, 118, 119

logging

flow log configuration, 178, 179, 183

flow log entry load balancing, 182

flow log export destination, 180

flow log export destination (information center), 181

flow log export destination (log host), 180

flow log host group configuration, 182

flow log host group configuration (IPv4), 183

flow log host group configuration (IPv6), 183

flow log timestamp, 181

flow log version, 181

information center common logs, 199

information center configuration, 199, 204, 213

information center custom log output (log host), 206

information center custom logs, 199

information center diagnostic log save (log file), 210

information center diagnostic logs, 199

information center duplicate log suppression, 211

information center hidden logs, 199

information center interface link up/link down log generation, 212

information center log default output rules, 200

information center log output (console), 204, 213

information center log output (Linux log host), 215

information center log output (log buffer), 207

information center log output (log host), 206, 206

information center log output (monitor terminal), 205

information center log output (UNIX log host), 214

information center log save (log file), 208

information center security log save (log file), 209

information center security logs, 199

information center synchronous log output, 211

information center system log destinations, 200

information center system log formats, 201

information center system log levels, 199

NETCONF logging enable, 114

SNMP configuration, 93

system information custom log default output rules, 201

system information diagnostic log default output rules, 200

system information hidden log default output rules, 201

system information security log default output rules, 201

system information trace log default output rules, 201

logical

capture filter expression, 193

capture filter operator, 189

display filter expression, 194

display filter operator, 192

logical operator

capture filter, 187

M

maintaining

flow log, 183

information center, 212

NMM packet capture, 196

PMM, 166

PMM kernel threads, 168

PMM Linux, 166

process monitoring and maintenance. See PMM

user PMM, 166

Management Information Base. Use MIB

managing

PoE PI priority policy configuration, 173

matching

NETCONF data filtering (conditional match), 139

NETCONF data filtering (regex match), 137

NMM NETCONF data filtering (column-based), 135

NMM NETCONF data filtering (column-based) (conditional match), 136

NMM NETCONF data filtering (column-based) (full match), 135

NMM NETCONF data filtering (column-based) (regex match), 136

NMM NETCONF data filtering (table-based), 134

message

NETCONF format, 111

NTP message processing disable, 74

NTP message source interface, 73

MIB

SNMP, 87, 87

SNMP Get operation, 88

SNMP Set operation, 88

SNMP view-based access control, 87

mirroring

port. See port mirroring

mode

NTP association, 63

NTP broadcast association, 59, 65

NTP client/server association, 59, 63

NTP multicast association, 59, 65

NTP symmetric active/passive association, 59, 64

SNMP access control (role-based), 88

SNMP access control (view-based), 88

module

feature module debug, 6

information center configuration, 199, 204, 213

NETCONF configuration data retrieval (all modules), 123

NETCONF configuration data retrieval (Syslog module), 125

monitor terminal

information center log output, 205

monitoring

EAA configuration, 154

EAA environment variable configuration (user-defined), 157

NQA client threshold monitoring, 19

NQA threshold monitoring, 8

PMM kernel thread, 167

PMM Linux, 166

PoE configuration, 173

process monitoring and maintenance. See PMM

multicast

NTP multicast association mode, 59, 65

NTP multicast client configuration, 65

NTP multicast mode authentication, 71

NTP multicast mode dynamic associations max, 74

NTP multicast server configuration, 66

N

NAT

flow log configuration, 178, 179, 183

information center custom log output (log host), 206

NAT444

information center custom log output (log host), 206

NETCONF

capability exchange, 115

CLI operations, 140, 140

CLI return, 144

configuration, 110, 113

configuration data retrieval (all modules), 123

configuration data retrieval (Syslog module), 125

configuration load, 128, 133

configuration lock/unlock, 118, 119

configuration rollback, 128

configuration rollback (configuration file-based), 128

configuration rollback (rollback point-based), 129

configuration save, 128, 128, 133

data entry retrieval (interface table), 126

data filtering, 134

data filtering (conditional match), 139

data filtering (regex match), 137

edit-config operation, 122

event notification subscription, 116, 117

get/get-bulk operation, 120

get-config/get-bulk-config operation, 122

message format, 111

NETCONF logging enable, 114

over SOAP, 111

over SOAP configuration, 113

over SSH enable, 114

parameter value change, 127

protocols and standards, 112

save-point/begin operation, 129

save-point/commit operation, 130

save-point/end operation, 131

save-point/get-commit-information operation, 132

save-point/get-commits operation, 131

save-point/rollback operation, 130

service operations, 120

session establishment, 114

session idle timeout time set, 115

session information retrieval, 142

session termination, 143

structure, 110

supported operations, 145

XML view, 115

network

feature module debug, 6

information center diagnostic log save (log file), 210

information center duplicate log suppression, 211

information center interface link up/link down log generation, 212

information center log minimum storage period, 210

information center log output (console), 213

information center log output (Linux log host), 215

information center log output (UNIX log host), 214

information center security log save (log file), 209

information center synchronous log output, 211

information center system log types, 199

local port mirroring, 221

local port mirroring group monitor port, 219

local port mirroring group source port, 219

Network Configuration Protocol. Use NETCONF

NQA client history record save, 22

NQA client operation, 10

NQA client operation (FTP), 12

NQA client operation (HTTP), 13

NQA client operation (ICMP echo), 10

NQA client operation (ICMP jitter), 11

NQA client operation (SNMP), 16

NQA client operation (TCP), 16

NQA client operation (UDP echo), 17

NQA client operation (UDP jitter), 14

NQA client operation optional parameters, 18

NQA client operation scheduling, 23

NQA client statistics collection, 21

NQA client template, 23

NQA client threshold monitoring, 19

NQA client+Track collaboration, 18

NQA collaboration configuration (on switch), 46

NQA echo operation configuration (ICMP), 34

NQA FTP operation configuration, 38

NQA FTP template configuration, 53

NQA HTTP operation configuration, 39

NQA HTTP template configuration, 52

NQA ICMP template configuration, 49

NQA operation configuration (ICMP jitter), 35

NQA RADIUS template configuration, 54

NQA server, 9

NQA SNMP operation configuration, 43

NQA TCP operation configuration, 44

NQA TCP template configuration, 50

NQA template configuration (HTTPS), 53

NQA template configuration (SSL), 55

NQA template configuration (TCP half open), 50

NQA UDP echo operation configuration, 45

NQA UDP jitter operation configuration, 40

NQA UDP template configuration, 51

ping connectivity test, 1

quality analyzer. See NQA

RMON alarm function configuration, 108

RMON Ethernet statistics group configuration, 105

RMON history group configuration, 106

SNMPv1 basics configuration, 89

SNMPv2c basics configuration, 89

SNMPv3 basics configuration, 91

tracert node failure identification, 4, 4

network management

EAA configuration, 154, 162

information center configuration, 199, 204, 213

NETCONF configuration, 110

NQA configuration, 7, 9, 34

NTP configuration, 76

packet capture configuration, 187

PMM Linux network, 166

PoE configuration, 176

port mirroring configuration, 217

RMON configuration, 105

SNMP configuration, 87

SNMPv1 configuration, 97

SNMPv2c configuration, 97

SNMPv3 configuration, 98

Network Time Protocol. Use NTP

NMM

displaying flow log, 183

displaying packet capture, 196

EAA configuration, 154, 162

EAA environment variable configuration (user-defined), 157

EAA event monitor, 154

EAA event monitor policy element, 155

EAA event monitor policy environment variable, 156

EAA event source, 154

EAA monitor policy, 155

EAA monitor policy configuration, 158

EAA monitor policy configuration (CLI), 158, 162

EAA monitor policy configuration (CLI+environment variables), 163

EAA monitor policy configuration (Tcl), 160, 164

EAA monitor policy suspension, 161

EAA RTM, 154

EAA settings display, 161

feature module debug, 6

flow log configuration, 178, 179, 183

flow log entry load balancing, 182

flow log export destination, 180

flow log host group configuration, 182

flow log host group configuration (IPv4), 183

flow log host group configuration (IPv6), 183

flow log packet source IP address, 181

flow log timestamp, 181

flow log version, 181

information center configuration, 199, 204, 213

information center custom log output (log host), 206

information center diagnostic log save (log file), 210

information center display, 212

information center duplicate log suppression, 211

information center enabling SNMP notifications for system logs, 212

information center interface link up/link down log generation, 212

information center log default output rules, 200

information center log destinations, 200

information center log formats, 201

information center log levels, 199

information center log minimum storage period, 210

information center log output (console), 204, 213

information center log output (Linux log host), 215

information center log output (log buffer), 207

information center log output (log host), 206, 206

information center log output (monitor terminal), 205

information center log output (UNIX log host), 214

information center log save (log file), 208

information center maintain, 212

information center security log save (log file), 209

information center synchronous log output, 211

information center system log types, 199

IPv6 NTP client/server association mode configuration, 77

IPv6 NTP symmetric active/passive association mode configuration, 79

local packet capture for AP radio configure, 195

local port mirroring, 221

local port mirroring group, 218

local port mirroring group monitor port, 219

local port mirroring group source port, 219

local port mirroring implementation, 217

maintaining flow log, 183

maintaining packet capture, 196

NETCONF capability exchange, 115

NETCONF CLI operations, 140, 140

NETCONF CLI return, 144

NETCONF configuration, 110, 113

NETCONF configuration data retrieval (all modules), 123

NETCONF configuration data retrieval (Syslog module), 125

NETCONF configuration load, 128

NETCONF configuration lock/unlock, 118, 119

NETCONF configuration rollback, 128

NETCONF configuration save, 128

NETCONF data entry retrieval (interface table), 126

NETCONF data filtering, 134

NETCONF edit-config operation, 122

NETCONF event notification subscription, 116, 117

NETCONF get/get-bulk operation, 120

NETCONF get-config/get-bulk-config operation, 122

NETCONF over SOAP configuration, 113

NETCONF over SSH enable, 114

NETCONF parameter value change, 127

NETCONF protocols and standards, 112

NETCONF save-point/begin operation, 129

NETCONF save-point/commit operation, 130

NETCONF save-point/end operation, 131

NETCONF save-point/get-commit-information operation, 132

NETCONF save-point/get-commits operation, 131

NETCONF save-point/rollback operation, 130

NETCONF service operations, 120

NETCONF session establishment, 114

NETCONF session information retrieval, 142

NETCONF session termination, 143

NETCONF structure, 110

NETCONF supported operations, 145

NQA client history record save, 22

NQA client operation, 10

NQA client operation (FTP), 12

NQA client operation (HTTP), 13

NQA client operation (ICMP echo), 10

NQA client operation (ICMP jitter), 11

NQA client operation (SNMP), 16

NQA client operation (TCP), 16

NQA client operation (UDP echo), 17

NQA client operation (UDP jitter), 14

NQA client operation optional parameters, 18

NQA client operation scheduling, 23

NQA client statistics collection, 21

NQA client template, 23

NQA client template (FTP), 30

NQA client template (HTTP), 27

NQA client template (HTTPS), 28

NQA client template (ICMP), 24

NQA client template (RADIUS), 31

NQA client template (SSL), 31

NQA client template (TCP half open), 25

NQA client template (TCP), 25

NQA client template (UDP), 26

NQA client template optional parameters, 32

NQA client threshold monitoring, 19

NQA client+Track collaboration, 18

NQA collaboration configuration (on switch), 46

NQA configuration, 7, 9, 34

NQA display, 33

NQA echo operation configuration (ICMP), 34

NQA FTP operation configuration, 38

NQA FTP template configuration, 53

NQA HTTP operation configuration, 39

NQA HTTP template configuration, 52

NQA ICMP template configuration, 49

NQA operation, 7

NQA operation configuration (ICMP jitter), 35

NQA RADIUS template configuration, 54

NQA server, 9

NQA SNMP operation configuration, 43

NQA TCP operation configuration, 44

NQA TCP template configuration, 50

NQA template configuration (HTTPS), 53

NQA template configuration (SSL), 55

NQA template configuration (TCP half open), 50

NQA threshold monitoring, 8

NQA UDP echo operation configuration, 45

NQA UDP jitter operation configuration, 40

NQA UDP template configuration, 51

NQA+Track collaboration, 8

NTP access control rights, 66

NTP architecture, 58

NTP association mode, 63

NTP authentication configuration, 67

NTP broadcast association mode configuration, 65

NTP broadcast mode authentication configuration, 70

NTP client/server association mode configuration, 76

NTP client/server mode authentication configuration, 67

NTP client/server mode with authentication, 81

NTP configuration, 57, 62

NTP display, 75

NTP dynamic associations max, 74

NTP enable, 63

NTP local clock as reference source, 75

NTP message processing disable, 74

NTP message source interface specification, 73

NTP multicast association mode, 65

NTP multicast mode authentication configuration, 71

NTP optional parameter configuration, 73

NTP packet DSCP value setting, 75

NTP protocols and standards, 62

NTP security, 61

NTP symmetric active/passive association mode configuration, 78

NTP symmetric active/passive mode authentication configuration, 69

packet capture configuration, 187

packet capture configure, 194

ping address reachability determination, 1

ping command, 1

ping connectivity test, 1

PoE configuration, 170, 171, 176

PoE display, 175

PoE monitoring configuration, 173

PoE PD detection (nonstandard), 172

PoE PI power max configuration, 172

PoE PI priority policy configuration, 173

PoE profile application, 175

PoE profile PI configuration, 174

PoE troubleshooting, 177

port mirroring classification, 217

port mirroring configuration, 217

port mirroring display, 220

remote packet capture for AP radio configure, 195

RMON alarm function configuration, 108

RMON alarm group sample type, 103

RMON configuration, 101, 105

RMON Ethernet statistics group configuration, 105

RMON group, 101

RMON history group configuration, 106

RMON private alarm group sample type, 103

RMON protocols and standards, 103

RMON settings display, 105

SNMP access control mode, 88

SNMP agent host notification, 95

SNMP basics configuration, 89

SNMP configuration, 87

SNMP framework, 87

SNMP Get operation, 88

SNMP logging configuration, 93

SNMP MIB, 87

SNMP notification, 94

SNMP protocol versions, 88

SNMP settings display, 96

SNMP view-based MIB access control, 87

SNMPv1 configuration, 97

SNMPv2c configuration, 97

SNMPv3 configuration, 98

SNTP authentication, 84

SNTP configuration, 83, 85

SNTP display, 85

SNTP enable, 83

SNTP NTP server specification, 83

system debugging, 1, 5

system information custom log default output rules, 201

system information diagnostic log default output rules, 200

system information hidden log default output rules, 201

system information security log default output rules, 201

system information trace log default output rules, 201

system maintenance, 1

tracert, 3

tracert node failure identification, 4, 4

NMS

RMON configuration, 101, 105

SNMP Notification operation, 88

SNMP protocol versions, 88

SNMP Set operation, 88, 88

notifying

NETCONF event notification subscription, 116, 117

SNMP agent host notification, 95

SNMP configuration, 87

SNMP notification, 94

SNMP Notification operation, 88

NQA

client enable, 9

client history record save, 22

client operation, 10

client operation (FTP), 12

client operation (HTTP), 13

client operation (ICMP echo), 10

client operation (ICMP jitter), 11

client operation (SNMP), 16

client operation (TCP), 16

client operation (UDP echo), 17

client operation (UDP jitter), 14

client operation optional parameters, 18

client operation scheduling, 23

client statistics collection, 21

client template (FTP), 30

client template (HTTP), 27

client template (HTTPS), 28

client template (ICMP), 24

client template (RADIUS), 31

client template (SSL), 31

client template (TCP half open), 25

client template (TCP), 25

client template (UDP), 26

client template configuration, 23

client template optional parameters, 32

client threshold monitoring, 19

client+Track collaboration, 18

collaboration configuration (on switch), 46

configuration, 7, 9, 34

display, 33

echo operation configuration (ICMP), 34

FTP operation configuration, 38

FTP template configuration, 53

HTTP operation configuration, 39

HTTP template configuration, 52

ICMP template configuration, 49

operation, 7

operation configuration (ICMP jitter), 35

RADIUS template configuration, 54

server configuration, 9

SNMP operation configuration, 43

TCP operation configuration, 44

TCP template configuration, 50

template configuration (HTTPS), 53

template configuration (SSL), 55

template configuration (TCP half open), 50

threshold monitoring, 8

Track collaboration function, 8

UDP echo operation configuration, 45

UDP jitter operation configuration, 40

UDP template configuration, 51

NTP

access control, 61, 61

access control rights configuration, 66

architecture, 58

association mode configuration, 63

authentication, 61

authentication configuration, 67

broadcast association mode, 59

broadcast association mode configuration, 65

broadcast client configuration, 65

broadcast mode authentication configuration, 70

broadcast mode dynamic associations max, 74

broadcast server configuration, 65

client/server association mode, 59

client/server association mode configuration, 63, 76

client/server mode authentication configuration, 67

client/server mode dynamic associations max, 74

client/server mode with authentication, 81

configuration, 57, 62, 76

configuration restrictions, 62

display, 75

enable, 63

how it works, 57

IPv6 client/server association mode configuration, 77

IPv6 symmetric active/passive association mode configuration, 79

local clock as reference source, 75

message processing disable, 74

message source interface specification, 73

multicast association mode, 59

multicast association mode configuration, 65

multicast client configuration, 65

multicast mode authentication configuration, 71

multicast mode dynamic associations max, 74

multicast server configuration, 66

optional parameter configuration, 73

packet DSCP value setting, 75

protocols and standards, 62

security, 61

SNTP authentication, 84

SNTP configuration, 83, 85

SNTP server specification, 83

symmetric active/passive association mode, 59

symmetric active/passive association mode configuration, 64, 78

symmetric active/passive mode authentication configuration, 69

symmetric active/passive mode dynamic associations max, 74

O

outbound

port mirroring, 217

outputting

information center log default output rules, 200

information center logs (Linux log host), 215

information center logs (log buffer), 207

information center logs (UNIX log host), 214

information center synchronous log output, 211

information custom logs to log host, 206

information logs (console), 204, 213

information logs (log host), 206, 206

information logs (monitor terminal), 205

P

packet

flow log packet source IP address, 181

NTP DSCP value setting, 75

port mirroring configuration, 217

SNTP configuration, 83, 85

packet capture

capture filter expression, 193

capture filter operator, 189

configuration, 187, 196

constant, 188

display filter expression, 194

display filter keyword, 190

display filter operator, 192

displaying, 196

feaure image-based packet capture, 187

local packet capture, 187, 187

local packet capture for AP radio configuration, 195

maintaining, 196

mode, 187

remote packet capture, 187, 187

remote packet capture for AP radio configuration, 195

variable, 188

parameter

NETCONF parameter value change, 127

NQA client history record save, 22

NQA client operation optional parameters, 18

NQA client template optional parameters, 32

NTP dynamic associations max, 74

NTP local clock as reference source, 75

NTP message processing disable, 74

NTP message source interface, 73

NTP optional parameter configuration, 73

SNMP basics configuration, 89

SNMPv1 basics configuration, 89

SNMPv2c basics configuration, 89

SNMPv3 basics configuration, 91

PD

PoE PD detection (nonstandard), 172

performing

NETCONF CLI operations, 140, 140

NETCONF edit-config operation, 122

NETCONF get/get-bulk operation, 120

NETCONF get-config/get-bulk-config operation, 122

NETCONF save-point/begin operation, 129

NETCONF save-point/commit operation, 130

NETCONF save-point/end operation, 131

NETCONF save-point/get-commit-information operation, 132

NETCONF save-point/get-commits operation, 131

NETCONF save-point/rollback operation, 130

NETCONF service operations, 120

PI

PoE enable, 171

PoE profile PI configuration, 174

power max configuration, 172

priority policy configuration, 173

troubleshooting PoE profile, 177

troubleshooting priority failure, 177

ping

address reachability determination, 1, 1

network connectivity test, 1

system maintenance, 1

PMM

command and hardware compatibility, 166

display, 166

kernel thread deadloop detection, 167

kernel thread monitoring, 167

kernel thread starvation detection, 168

Linux kernel thread, 166

Linux network, 166

Linux user, 166

maintain, 166

user PMM display, 166

user PMM maintain, 166

PoE

configuration, 170, 171, 176

display, 175

enable for PI, 171

monitoring configuration, 173

PD detection (nonstandard), 172

PI power max configuration, 172

PI priority policy configuration, 173

profile application, 175

profile PI configuration, 174

troubleshoot, 177

troubleshoot PI critical priority failure, 177

troubleshoot PoE profile failure, 177

policy

EAA configuration, 154, 162

EAA environment variable configuration (user-defined), 157

EAA event monitor policy element, 155

EAA event monitor policy environment variable, 156

EAA monitor policy, 155

EAA monitor policy configuration, 158

EAA monitor policy configuration (CLI), 158, 162

EAA monitor policy configuration (CLI+environment variables), 163

EAA monitor policy configuration (Tcl), 160, 164

EAA monitor policy suspension, 161

port

flow log configuration, 178, 179, 183

IPv6 NTP client/server association mode, 77

IPv6 NTP symmetric active/passive association mode, 79

mirroring. See port mirroring

NTP association mode, 63

NTP client/server association mode, 76

NTP client/server mode with authentication, 81

NTP configuration, 57, 62

NTP symmetric active/passive association mode, 78

SNTP configuration, 83, 85

port mirroring

configuration, 217

display, 220

local group creation, 218

local group monitor port, 219

local group monitor port configuration restrictions, 220

local group source port, 219

local group source port configuration restrictions, 219

local mirroring configuration, 221

terminology, 217

power

over Ethernet. Use PoE

PoE configuration, 176

PoE PI max configuration, 172

PoE PI priority policy configuration, 173

sourcing equipment. Use PSE

private

RMON private alarm group, 102

RMON private alarm group sample type, 103

procedure

applying PoE profile, 175

applying PoE profile (multiple PIs in system view), 175

applying PoE profile (single PI in PI view), 175

changing NETCONF parameter value, 127

configuration NETCONF over SOAP, 113

configuring EAA environment variable (user-defined), 157

configuring EAA monitor policy, 158

configuring EAA monitor policy (CLI), 158, 162

configuring EAA monitor policy (CLI+environment variables), 163

configuring EAA monitor policy (Tcl), 160, 164

configuring flow log, 179, 183

configuring flow log export to flow log host group, 185

configuring flow log host group, 182

configuring flow log host group (IPv4), 183

configuring flow log host group (IPv6), 183

configuring flow log packet source IP address, 181

configuring flow log timestamp, 181

configuring flow log version, 181

configuring information center, 204

configuring IPv6 NTP client/server association mode, 77

configuring IPv6 NTP symmetric active/passive association mode, 79

configuring local packet capture, 196

configuring local packet capture for AP radio, 195

configuring local port mirroring, 221

configuring local port mirroring group monitor port, 219

configuring local port mirroring group monitor port (interface view), 220

configuring local port mirroring group monitor port (system view), 220

configuring local port mirroring group source ports, 219

configuring local port mirroring group source ports (interface view), 219

configuring local port mirroring group source ports (system view), 219

configuring NETCONF, 113

configuring NQA, 9

configuring NQA client history record save, 22

configuring NQA client operation, 10

configuring NQA client operation (FTP), 12

configuring NQA client operation (HTTP), 13

configuring NQA client operation (ICMP echo), 10

configuring NQA client operation (ICMP jitter), 11

configuring NQA client operation (SNMP), 16

configuring NQA client operation (TCP), 16

configuring NQA client operation (UDP echo), 17

configuring NQA client operation (UDP jitter), 14

configuring NQA client operation optional parameters, 18

configuring NQA client statistics collection, 21

configuring NQA client template, 23

configuring NQA client template (FTP), 30

configuring NQA client template (HTTP), 27

configuring NQA client template (HTTPS), 28

configuring NQA client template (ICMP), 24

configuring NQA client template (RADIUS), 31

configuring NQA client template (SSL), 31

configuring NQA client template (TCP half open), 25

configuring NQA client template (TCP), 25

configuring NQA client template (UDP), 26

configuring NQA client template optional parameters, 32

configuring NQA client threshold monitoring, 19

configuring NQA client+Track collaboration, 18

configuring NQA collaboration (on switch), 46

configuring NQA FTP operation, 38

configuring NQA FTP template, 53

configuring NQA HTTP operation, 39

configuring NQA HTTP template, 52

configuring NQA ICMP template, 49

configuring NQA operation (ICMP jitter), 35

configuring NQA RADIUS template, 54

configuring NQA server, 9

configuring NQA SNMP operation, 43

configuring NQA TCP, 44

configuring NQA TCP template, 50

configuring NQA template (HTTPS), 53

configuring NQA template (SSL), 55

configuring NQA template (TCP half open), 50

configuring NQA UDP echo operation, 45

configuring NQA UDP jitter operation, 40

configuring NQA UDP template, 51

configuring NTP, 62

configuring NTP access control rights, 66

configuring NTP association mode, 63

configuring NTP authentication, 67

configuring NTP broadcast association mode, 65

configuring NTP broadcast client, 65

configuring NTP broadcast mode authentication, 70

configuring NTP broadcast server, 65

configuring NTP client/server association mode, 63, 76

configuring NTP client/server mode authentication, 67

configuring NTP client/server mode with authentication, 81

configuring NTP dynamic associations max, 74

configuring NTP local clock as reference source, 75

configuring NTP multicast association mode, 65

configuring NTP multicast client, 65

configuring NTP multicast mode authentication, 71

configuring NTP multicast server, 66

configuring NTP optional parameters, 73

configuring NTP symmetric active/passive association mode, 64, 78

configuring NTP symmetric active/passive mode authentication, 69

configuring packet capture, 194, 196

configuring PMM kernel thread deadloop detection, 167

configuring PMM kernel thread starvation detection, 168

configuring PoE, 171, 176

configuring PoE monitoring, 173

configuring PoE PI power max, 172

configuring PoE PI priority policy, 173

configuring PoE profile PI, 174

configuring remote packet capture, 197

configuring remote packet capture for AP radio, 195

configuring RMON, 105

configuring RMON alarm function, 104, 108

configuring RMON Ethernet statistics group, 105

configuring RMON history group, 106

configuring RMON statistics function, 103

configuring SNMP basic parameters, 89

configuring SNMP logging, 93

configuring SNMP notification, 94

configuring SNMPv1, 97

configuring SNMPv1 agent host notification, 95

configuring SNMPv1 basics, 89

configuring SNMPv2c, 97

configuring SNMPv2c agent host notification, 95

configuring SNMPv2c basics, 89

configuring SNMPv3, 98

configuring SNMPv3 agent host notification, 95

configuring SNMPv3 basic parameters, 91

configuring SNTP, 85

configuring SNTP authentication, 84

creating local port mirroring group, 218

creating RMON Ethernet statistics entry, 103

creating RMON history control entry, 103

debugging feature module, 6

determining ping address reachability, 1

disabling information center interface link up/link down log generation, 212

disabling NTP message interface processing, 74

displaying EAA settings, 161

displaying flow log, 183

displaying information center, 212

displaying NMM packet capture, 196

displaying NQA, 33

displaying NTP, 75

displaying PMM, 166

displaying PMM kernel threads, 168

displaying PoE, 175

displaying port mirroring, 220

displaying RMON settings, 105

displaying SNMP settings, 96

displaying SNTP, 85

displaying user PMM, 166

enabling flow log entry load balancing, 182

enabling information center duplicate log suppression, 211

enabling information center synchronous log output, 211

enabling NETCONF logging, 114

enabling NETCONF over SSH, 114

enabling NQA client, 9

enabling NTP, 63

enabling PoE PD detection (nonstandard), 172

enabling PoE PI, 171

enabling SNMP notification, 94

enabling SNMP notifications for system logs, 212

enabling SNTP, 83

entering NETCONF XML view, 115

establishing NETCONF session, 114

exchanging NETCONF capabilities, 115

filtering NETCONF data (conditional match), 139

filtering NETCONF data (regex match), 137

filtering NMM NETCONF data, 134

identifying tracert node failure, 4, 4

loading NETCONF configuration, 128, 133

locking NETCONF configuration, 118, 119

maintaining flow log, 183

maintaining information center, 212

maintaining NMM packet capture, 196

maintaining PMM, 166

maintaining PMM kernel threads, 168

maintaining user PMM, 166

monitoring PMM kernel thread, 167

outputting information center custom logs to log host, 206

outputting information center logs (console), 204, 213

outputting information center logs (Linux log host), 215

outputting information center logs (log buffer), 207

outputting information center logs (log host), 206, 206

outputting information center logs (monitor terminal), 205

outputting information center logs (UNIX log host), 214

performing NETCONF CLI operations, 140, 140

performing NETCONF edit-config operation, 122

performing NETCONF get/get-bulk operation, 120

performing NETCONF get-config/get-bulk-config operation, 122

performing NETCONF save-point/begin operation, 129

performing NETCONF save-point/commit operation, 130

performing NETCONF save-point/end operation, 131

performing NETCONF save-point/get-commit-information operation, 132

performing NETCONF save-point/get-commits operation, 131

performing NETCONF save-point/rollback operation, 130

performing NETCONF service operations, 120

retrieving NETCONF configuration data (all modules), 123

retrieving NETCONF configuration data (Syslog module), 125

retrieving NETCONF data entry (interface table), 126

retrieving NETCONF session information, 142

returning to NETCONF CLI, 144

rolling back NETCONF configuration, 128

rolling back NETCONF configuration (configuration file-based), 128

rolling back NETCONF configuration (rollback point-based), 129

saving information center diagnostic logs (log file), 210

saving information center log (log file), 208

saving information center security logs (log file), 209

saving NETCONF configuration, 128, 128, 133

scheduling NQA client operation, 23

setting log minimum storage period, 210

setting NETCONF session idle timeout time, 115

setting NTP packet DSCP value, 75

specifying flow log export destination, 180

specifying flow log export destination (information center), 181

specifying flow log export destination (log host), 180

specifying NTP message source interface, 73

specifying SNTP NTP server, 83

subscribing to NETCONF event notifications, 116, 117

suspending EAA monitor policy, 161

terminating NETCONF session, 143

testing network connectivity with ping, 1

unlocking NETCONF configuration, 118, 119

process

monitoring and maintenance. See PMM

profile

PoE profile application, 175

PoE profile PI configuration, 174

protocol

capture filter expression, 193

display filter expression, 194

display filter keyword, 190

protocols and standards

NETCONF, 110, 112

NTP, 62

RMON, 103

SNMP configuration, 87

SNMP versions, 88

PSE

PoE configuration, 170, 171, 176

R

RADIUS

NQA client template, 31

NQA template configuration, 54

real-time

event manager. See RTM

regex match

NETCONF data filtering, 137

NETCONF data filtering (column-based), 136

regular expression. Use regex

remote

remote packet capture, 187

remote packet capture for AP radio configuration, 195

Remote Network Monitoring. Use RMON

remote packet capture

configuration, 197

restrictions

EAA monitor policy configuration, 158

local port mirroring group monitor port configuration, 220

local port mirroring group source port configuration, 219

NTP configuration, 62

SNTP configuration, 62

SNTP configuration restrictions, 83

retrieving

NETCONF configuration data (all modules), 123

NETCONF configuration data (Syslog module), 125

NETCONF data entry (interface table), 126

NETCONF session information, 142

returning

NETCONF CLI return, 144

RMON

alarm function configuration, 104, 108

alarm group, 102

configuration, 101, 105

Ethernet statistics entry creation, 103

Ethernet statistics group, 101

Ethernet statistics group configuration, 105

event group, 101

group, 101

group sample type (alarm group), 103

group sample type (private alarm), 103

history control entry creation, 103

history group, 101

history group configuration, 106

private alarm group, 102

protocols and standards, 103

settings display, 105

statistics function configuration, 103

role

SNMP access control (role-based), 88

rollback

NETCONF save-point/begin operation, 129

NETCONF save-point/commit operation, 130

NETCONF save-point/end operation, 131

NETCONF save-point/get-commit-information operation, 132

NETCONF save-point/get-commits operation, 131

NETCONF save-point/rollback operation, 130

rolling back

NETCONF configuration, 128

NETCONF configuration (configuration file-based), 128

NETCONF configuration (rollback point-based), 129

routing

IPv6 NTP client/server association mode, 77

IPv6 NTP symmetric active/passive association mode, 79

NTP association mode, 63

NTP client/server association mode, 76

NTP client/server mode with authentication, 81

NTP configuration, 57, 62

NTP symmetric active/passive association mode, 78

SNTP configuration, 83, 85

RTM

EAA, 154

EAA configuration, 154, 162

rule

information center log default output rules, 200

system information default custom log output, 201

system information default diagnostic log output rules, 200

system information default hidden log output, 201

system information default security log output, 201

system information default trace log output, 201

runtime

EAA event monitor policy runtime, 156

S

sampling

RMON alarm group sample type, 103

RMON private alarm group sample type, 103

saving

information center diagnostic logs (log file), 210

information center log (log file), 208

information center security logs (log file), 209

NETCONF configuration, 128, 128, 133

NQA client history records, 22

scheduling

NQA client operation, 23

security

information center security log save (log file), 209

information center security logs, 199

NTP, 61

NTP access control rights, 66

NTP authentication, 61, 67

NTP broadcast mode authentication, 70

NTP client/server mode authentication, 67

NTP multicast mode authentication, 71

NTP symmetric active/passive mode authentication, 69

SNTP authentication, 84

server

NQA configuration, 9

NTP broadcast server configuration, 65

NTP multicast server configuration, 66

SNTP configuration, 83, 85

SNTP NTP server specification, 83

service

NETCONF configuration data retrieval (all modules), 123

NETCONF configuration data retrieval (Syslog module), 125

NETCONF configuration load, 128

NETCONF configuration rollback, 128

NETCONF configuration save, 128

NETCONF edit-config operation, 122

NETCONF get/get-bulk operation, 120

NETCONF get-config/get-bulk-config operation, 122

NETCONF operations, 120

NETCONF parameter value change, 127

session

NETCONF session establishment, 114

NETCONF session idle timeout time, 115

NETCONF session information retrieval, 142

NETCONF session termination, 143

set operation

SNMP, 88

SNMP logging, 93

setting

log minimum storage period, 210

NETCONF session idle timeout time, 115

severity level (system information), 199

Simple Network Management Protocol. Use SNMP

Simplified NTP. See SNTP

SNMP

access control mode, 88

agent, 87

basic parameter configuration, 89

configuration, 87

FIPS compliance, 89

framework, 87

Get operation, 88, 93

logging configuration, 93

manager, 87

MIB, 87, 87

MIB view-based access control, 87

notification configuration, 94

notification enable, 94

Notification operation, 88

NQA, 7

NQA client operation, 16

NQA operation configuration, 43

protocol versions, 88

RMON configuration, 101, 105

Set operation, 88, 93

settings display, 96

SNMPv1 basic parameter configuration, 89

SNMPv1 configuration, 97

SNMPv2c basic parameter configuration, 89

SNMPv2c configuration, 97

SNMPv3 basic parameter configuration, 91

SNMPv3 configuration, 98

SNMPv1

agent host notification, 95

basic parameter configuration, 89

configuration, 97

Notification operation, 88

protocol version, 88

SNMPv2c

agent host notification, 95

basic parameter configuration, 89

configuration, 97

Notification operation, 88

protocol version, 88

SNMPv3

agent host notification, 95

basic parameter configuration, 91

configuration, 98

Notification operation, 88

protocol version, 88

SNTP

authentication, 84

configuration, 83, 85

configuration restrictions, 62, 83

display, 85

enable, 83

NTP server specification, 83

SOAP

NETCONF message format, 111

NETCONF over SOAP configuration, 113

source

flow log packet source IP address, 181

port mirroring source, 217

port mirroring source device, 217

specifying

flow log export destination, 180

flow log export destination (information center), 181

flow log export destination (log host), 180

flow log packet source IP address, 181

NTP message source interface, 73

SNTP NTP server, 83

SSH

NETCONF over SSH enable, 114

SSL

NQA client template (SSL), 31

NQA template configuration (SSL), 55

starvation detection (Linux kernel thread PMM), 168

statistics

NQA client statistics collection, 21

RMON configuration, 101, 105

RMON Ethernet statistics entry, 103

RMON Ethernet statistics group, 101

RMON Ethernet statistics group configuration, 105

RMON history control entry, 103

RMON statistics function, 103

subscribing

NETCONF event notification, 116, 117

suppressing

information center duplicate log suppression, 211

suspending

EAA monitor policy, 161

switch

module debug, 6

NQA collaboration configuration, 46

screen output, 6

symmetric

IPv6 NTP symmetric active/passive association mode, 79

NTP symmetric active/passive association mode, 59, 64, 69, 78

NTP symmetric active/passive mode dynamic associations max, 74

synchronizing

information center synchronous log output, 211

NTP configuration, 57, 62

SNTP configuration, 83, 85

syslog

NETCONF configuration data retrieval (Syslog module), 125

system

custom log default output rules, 201

diagnostic log default output rules, 200

hidden log default output rules, 201

information center custom log output (log host), 206

information center duplicate log suppression, 211

information center interface link up/link down log generation, 212

information center log destinations, 200

information center log levels, 199

information center log output (console), 204, 213

information center log output (Linux log host), 215

information center log output (log buffer), 207

information center log output (log host), 206, 206

information center log output (monitor terminal), 205

information center log output (UNIX log host), 214

information center log save (log file), 208

information center log types, 199

information center security log save (log file), 209

information center synchronous log output, 211

information log formats, 201

log default output rules, 200

security log default output rules, 201

trace log default output rules, 201

system administration

debugging, 1

feature module debug, 6

ping, 1

ping address reachability, 1

ping command, 1

ping connectivity test, 1

system debugging, 5

tracert, 1, 3

tracert node failure identification, 4, 4

system information

information center configuration, 199, 204, 213

T

table

NETCONF data entry retrieval (interface table), 126

Tcl

EAA configuration, 154, 162

EAA monitor policy configuration, 160, 164

TCP

NQA, 7

NQA client operation, 16

NQA client template, 25

NQA client template (TCP half open), 25

NQA operation configuration, 44

NQA template configuration, 50

TCP half open

NQA template configuration (TCP half open), 50

template

NQA client template, 23

NQA client template (FTP), 30

NQA client template (HTTP), 27

NQA client template (HTTPS), 28

NQA client template (ICMP), 24

NQA client template (RADIUS), 31

NQA client template (SSL), 31

NQA client template (TCP half open), 25

NQA client template (TCP), 25

NQA client template (UDP), 26

NQA client template optional parameters, 32

NQA FTP template configuration, 53

NQA HTTP template configuration, 52

NQA ICMP template configuration, 49

NQA RADIUS template configuration, 54

NQA TCP template configuration, 50

NQA template configuration (HTTPS), 53

NQA template configuration (SSL), 55

NQA template configuration (TCP half open), 50

NQA UDP template configuration, 51

terminating

NETCONF session, 143

testing

ping network connectivity test, 1

threshold

NQA client threshold monitoring, 8, 19

NQA operation reaction entry, 19

NQA operation support accumulate type, 19

NQA operation support average type, 19

NQA operation support consecutive type, 19

NQA operation triggered action none, 19

NQA operation triggered action trap-only, 19

NQA operation triggered action trigger-only, 19

time

NTP configuration, 57, 62

NTP local clock as reference source, 75

SNTP configuration, 83, 85

timeout

NETCONF session idle timeout time, 115

timestamp

flow log timestamp configuration, 181

tracert

IP address retrieval, 3

node failure detection, 3, 4, 4

system maintenance, 1

Track

NQA client+Track collaboration, 18

NQA collaboration, 8

NQA collaboration configuration (on switch), 46

traffic

RMON configuration, 101, 105

trapping

SNMP notification, 94

triggering

NQA operation threshold triggered action none, 19

NQA operation threshold triggered action trap-only, 19

NQA operation threshold triggered action trigger-only, 19

troubleshooting

PI critical priority failure, 177

PoE, 177

PoE profile failure, 177

U

UDP

IPv6 NTP client/server association mode, 77

IPv6 NTP symmetric active/passive association mode, 79

NQA, 7

NQA client operation (UDP echo), 17

NQA client operation (UDP jitter), 14

NQA client template, 26

NQA jitter operation configuration, 40

NQA template configuration, 51

NQA UDP echo operation configuration, 45

NTP association mode, 63

NTP client/server association mode, 76

NTP client/server mode with authentication, 81

NTP configuration, 57, 62

NTP symmetric active/passive association mode, 78

UNIX

information center log host output, 214

unlocking

NETCONF configuration, 118, 119

user

PMM Linux user, 166

V

value

NETCONF parameter value change, 127

variable

capture filter keyword, 188

EAA environment variable configuration (user-defined), 157

EAA event monitor policy environment (user-defined), 157

EAA event monitor policy environment system-defined (event-specific), 156

EAA event monitor policy environment system-defined (public), 156

EAA event monitor policy environment variable, 156

EAA monitor policy configuration (CLI+environment variables), 163

view

SNMP access control (view-based), 88

VLAN

capture filter expression, 193

X

XML

NETCONF capability exchange, 115

NETCONF configuration, 110, 113

NETCONF data filtering (conditional match), 139

NETCONF data filtering (regex match), 137

NETCONF message format, 111

NETCONF structure, 110

NETCONF XML view, 115

NMM NETCONF data filtering, 134

XSD

NETCONF message format, 111

 

  • Cloud & AI
  • InterConnect
  • Intelligent Computing
  • Security
  • SMB Products
  • Intelligent Terminal Products
  • Product Support Services
  • Technical Service Solutions
All Services
  • Resource Center
  • Policy
  • Online Help
All Support
  • Become a Partner
  • Partner Resources
  • Partner Business Management
All Partners
  • Profile
  • News & Events
  • Online Exhibition Center
  • Contact Us
All About Us
新华三官网