HP FlexFabric 7900 Switch Series Network Management and Monitoring Configuration Guide Part number: 5998-4288 Software version: Release 2109 Document version: 6W100-20140122
Legal and notice information © Copyright 2014 Hewlett-Packard Development Company, L.P. No part of this documentation may be reproduced or transmitted in any form or by any means without prior written consent of Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Contents Using ping, tracert, and system debugging ··············································································································· 1 Ping ····················································································································································································· 1 Using a ping command to test network connectivity ···························································································· 1 Ping example
Enabling the SNTP service ············································································································································ 39 Specifying an NTP server for the device ····················································································································· 39 Configuring SNTP authentication ································································································································· 40 Displaying and m
Local port mirroring configuration task list ········································································································· 75 Creating a local mirroring group ························································································································ 76 Configuring source ports for the local mirroring group ···················································································· 76 Configuring source CPUs for the local mirroring group·····
Configuring the ICMP echo operation ·············································································································· 106 Configuring the DHCP operation······················································································································· 106 Configuring the DNS operation ························································································································· 107 Configuring the FTP operation ·····················
Establishing a NETCONF session ······························································································································ 157 Entering xml view ················································································································································ 157 Exchanging capabilities ····································································································································· 157 Subscribing to event
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 a specific 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.
Configuration procedure # Use the ping command on Device A to test connectivity to Device C. Ping 1.1.2.2 (1.1.2.2): 56 data bytes, press CTRL_C to break 56 bytes from 1.1.2.2: icmp_seq=0 ttl=254 time=2.137 ms 56 bytes from 1.1.2.2: icmp_seq=1 ttl=254 time=2.051 ms 56 bytes from 1.1.2.2: icmp_seq=2 ttl=254 time=1.996 ms 56 bytes from 1.1.2.2: icmp_seq=3 ttl=254 time=1.963 ms 56 bytes from 1.1.2.2: icmp_seq=4 ttl=254 time=1.991 ms --- Ping statistics for 1.1.2.
Tracert Tracert (also called "Traceroute") enables retrieval of the IP addresses of Layer 3 devices in the path to a specific destination. In the event of network failure, use tracert to test network connectivity and identify failed nodes. Figure 2 Tracert operation Device A Device B Device C 1.1.2.1/24 1.1.1.1/24 1.1.2.2/24 1.1.1.2/24 Device D 1.1.3.1/24 1.1.3.
Enable sending of ICMP destination unreachable packets on the destination device. If the destination device is an HP device, execute the ip 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.
# Enable sending of ICMP timeout packets on Device B. system-view [DeviceB] ip ttl-expires enable # Enable sending of ICMP destination unreachable packets on Device C. system-view [DeviceC] ip unreachables enable # Execute the tracert command on Device A. 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.
Figure 4 Relationship between the module and screen output switch Debugging a feature module Output of debugging commands is memory intensive. To guarantee system performance, enable debugging only for modules that are in an exceptional condition. When debugging is complete, use the undo debugging all command to disable all the debugging functions. To debug a feature module: Step Command Remarks 1. Enable debugging for a specified module in user view.
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.
Figure 5 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).
Figure 6 NTP architecture Authoritative clock Primary servers (Stratum 1) Secondary servers (Stratum 2) Tertiary servers (Stratum 3) Quaternary servers (Stratum 4) Server Client Symmetric peer Symmetric Broadcast/multicast Broadcast/multicast client peer server Typically, a stratum 1 NTP server gets its time from an authoritative time source, such as an atomic clock, and provides time for other devices as the primary NTP server.
Table 1 NTP association modes Mode Working process Principle Application scenario A client can be synchronized to a server, but a server cannot be synchronized to a client. As Figure 6 shows, this mode is intended for configurations where devices of a higher stratum are synchronized to devices with a lower stratum. A symmetric active peer and a symmetric passive peer can be synchronized to each other.
Mode Broadcast Working process Principle 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.
• If no NTP access control is configured, peer is granted to the local device and peer devices. • If the IP address of the peer device matches a permit statement in an ACL for more than one access right, the least restrictive access right is granted to the peer device. If a deny statement or no ACL is matched, no access right is granted. • If no ACL is created for a specific access right, the associated access right is not granted. • If no ACL is created for any access right, peer is granted.
• To ensure time synchronization accuracy, do not specify different reference sources for a symmetric active peer and a symmetric passive peer if they operate as the NTP client for the client/server, broadcast, and multicast modes. • You can use the clock protocol command to specify the system time source. For more information about the clock protocol command, see Fundamentals Command Reference. Configuration task list Tasks at a glance (Required.) Enabling the NTP service (Required.
Step 1. 2. Command Remarks Enter system view. system-view N/A 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 ] * 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.
Step 3. Command Configure the device to operate in broadcast client mode. Remarks By default, the device does not operate in broadcast client mode. ntp-service broadcast-client After you execute the command, the device receives NTP broadcast messages from the specified interface. Command Remarks Configuring the broadcast server Step 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.
Step 3. Command Configure the device to operate in multicast server mode. ntp-service multicast-server [ ip-address ] [ authentication-keyid keyid | ttl ttl-number | version number ] * Remarks By default, the device does not operate in multicast server mode. After you execute the command, the device receives NTP multicast messages from the specified interface. Configuring access control rights Step Command Remarks 1. Enter system view. system-view N/A 2.
Step 5. Associate the specified key with an NTP server. Command Remarks ntp-service unicast-server { server-name | ip-address } authentication-keyid keyid N/A To configure NTP authentication for a server: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable NTP authentication. ntp-service authentication enable By default, NTP authentication is disabled. 3. Configure an NTP authentication key.
Client Enable NTP authentication No Server Configure a key and configure it as a trusted key N/A Associate the key with an NTP server N/A Enable NTP authentication N/A Configure a key and configure it as a trusted key N/A Authentication result No authentication. NTP messages can be sent and received correctly.
NTP authentication results differ when different configurations are performed on active peer and passive peer. For more information, see Table 3. (N/A in the table means that whether the configuration is performed does not make any difference.
Active peer Enable NTP authentication Passive peer Configure a key and configure it as a trusted key Associate the key with a passive peer Enable NTP authentication Configure a key and configure it as a trusted key Authentication result The active peer has a higher stratum than the passive peer. Yes No Yes N/A N/A Failed. NTP messages cannot be sent and received correctly. N/A Failed. NTP messages cannot be sent and received correctly. N/A No authentication.
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 } value By default, no NTP authentication key is configured. 4. Configure the key as a trusted key.
Broadcast server Enable NTP authentication Yes Yes No No Broadcast client Configure a key and configure it as a trusted key N/A N/A N/A N/A Associate the key with a broadcast server No Enable NTP authentication Yes No No N/A Yes N/A No Configure a key and configure it as a trusted key Authentication result N/A Failed. NTP messages cannot be sent and received correctly. N/A No authentication. NTP messages can be sent and received correctly. N/A Failed.
Step Command Remarks 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 } value 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.
Multicast server Enable NTP authentication Yes Yes No No Multicast client Configure a key and configure it as a trusted key N/A N/A N/A N/A Associate the key with a multicast server No Enable NTP authentication Yes No No N/A Yes N/A No Configure a key and configure it as a trusted key Authentication result N/A Failed. NTP messages cannot be sent and received correctly. N/A No authentication. NTP messages can be sent and received correctly. N/A Failed.
Step Command Remarks 1. Enter system view. system-view N/A 2. Specify the source interface for NTP messages. ntp-service source-interface 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.
Step Configure the maximum number of dynamic sessions allowed to be established. 2. Command Remarks ntp-service max-dynamic-sessions number By default, the command can establish up to 100 dynamic sessions. Configuring a DSCP value for NTP packets The DSCP value determines the sending precedence of a packet. To configure a DSCP value for NTP packets: Step Command Remarks 1. Enter system view. system-view N/A 2. Set a DSCP value for NTP packets.
NTP client/server mode configuration example Network requirements As shown in Figure 8, the local clock of Device A is to be used as a reference source, with the stratum level 2. Device B operates in client mode and Device A is to be used as the NTP server for Device B. Figure 8 Network diagram Configuration procedure 1. Set the IP address for each interface as shown in Figure 8. (Details not shown.) 2. Configure Device A: # Enable the NTP service.
[DeviceB] 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 The output shows that an association has been set up between Device B and Device A.
# Enable the NTP service. [DeviceB] ntp-service enable # Specify Device A as the NTP server of Device B. [DeviceB] ntp-service unicast-server 3.0.1.31 4. Configure Device C: # Enable the NTP service. system-view [DeviceC] ntp-service enable # Specify the local clock as the reference source, with the stratum level 2. [DeviceC] ntp-service refclock-master 2 # Configure Device B as a symmetric passive peer. [DeviceC] ntp-service unicast-peer 3.0.1.32 5.
NTP broadcast mode configuration example Network requirements As shown in Figure 10, Switch C functions as the NTP server for multiple devices on a network segment and synchronizes the time among multiple devices. • Switch C's local clock is to be used as a reference source, with the stratum level 2. • Switch C operates in broadcast server mode and sends out broadcast messages from VLAN-interface 2.
[SwitchA] interface vlan-interface 2 [SwitchA-Vlan-interface2] ntp-service broadcast-client 4. Configure Switch B: # Enable the NTP service. system-view [SwitchB] ntp-service enable # Configure Switch B to operate in broadcast client mode and receive broadcast messages on VLAN-interface 2. [SwitchB] interface vlan-interface 2 [SwitchB-Vlan-interface2] ntp-service broadcast-client 5.
• Switch A and Switch D operate in multicast client mode and receive multicast messages through VLAN-interface 3 and VLAN-interface 2, respectively. Figure 11 Network diagram Vlan-int2 3.0.1.31/24 Switch C NTP multicast server Vlan-int3 1.0.1.11/24 Vlan-int3 1.0.1.10/24 Switch A NTP multicast client Vlan-int2 3.0.1.30/24 Switch B Vlan-int2 3.0.1.32/24 Switch D NTP multicast client Configuration procedure In this example, Switch B must support IPv4 multicast routing. 1.
System peer: 3.0.1.31 Local mode: bclient Reference clock ID: 3.0.1.31 Leap indicator: 00 Clock jitter: 0.044281 s Stability: 0.000 pps Clock precision: 2^-10 Root delay: 0.00229 ms Root dispersion: 4.12572 ms Reference time: d0d289fe.ec43c720 Sat, Jan 8 2011 7:00:14.922 The output shows that Switch D has been synchronized to Switch C, the clock stratum level of Switch D is 3, and that of Switch C is 2. # Display IPv4 NTP association information for Switch D.
[SwitchA] interface vlan-interface 3 [SwitchA-Vlan-interface3] ntp-service multicast-client 7. Verify the configuration: # Display the NTP status of Switch A after clock synchronization. [SwitchA-Vlan-interface3] display ntp-service status Clock status: synchronized Clock stratum: 3 System peer: 3.0.1.31 Local mode: bclient Reference clock ID: 3.0.1.31 Leap indicator: 00 Clock jitter: 0.165741 s Stability: 0.000 pps Clock precision: 2^-10 Root delay: 0.00534 ms Root dispersion: 4.
Configuration procedure 1. Set the IP address for each interface as shown in Figure 12. (Details not shown.) 2. Configure Device A: # Enable the NTP service. system-view [DeviceA] ntp-service enable # Specify the local clock as the reference source, with the stratum level 2. [DeviceA] ntp-service refclock-master 2 3. Configure Device B: # Enable the NTP service. system-view [DeviceB] ntp-service enable # Enable NTP authentication on Device B.
Reference time: d0c62687.ab1bba7d Wed, Dec 29 2010 21:28:39.668 The output shows that Device B has been synchronized to Device A, the clock stratum level of Device B is 3, and that of Device A is 2. # Display IPv4 NTP association information for Device B. [DeviceB] 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.
# Enable the NTP service. system-view [SwitchA] ntp-service enable # Enable NTP authentication on Switch A. Configure an NTP authentication key, with the key ID of 88 and key value of 123456. Input the key in plain text, and specify it as a trusted key.
# Enable NTP authentication on Switch C. Configure an NTP authentication key, with the key ID of 88 and key value of 123456. Input the key in plain text, and specify it as a trusted key. [SwitchC] ntp-service authentication enable [SwitchC] ntp-service authentication-keyid 88 authentication-mode md5 simple 123456 [SwitchC] ntp-service reliable authentication-keyid 88 # Specify Switch C as an NTP broadcast server, and associate the key 88 with Switch C.
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.
Step Command Specify an NTP server for the device. 2. sntp unicast-server { server-name | ip-address } [ authentication-keyid keyid | source interface-type interface-number | version number ] * Remarks 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.
Displaying and maintaining SNTP Execute display commands in any view. Task Command Display information about all SNTP associations. display sntp sessions SNTP configuration example Network requirements As shown in Figure 14, do the following: • Configure the local clock of Device A as a reference source, with the stratum level 2. • Configure Device B to operate in SNTP client mode, and specify Device A as the NTP server.
[DeviceB] 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. [DeviceB] sntp authentication-keyid 10 authentication-mode md5 simple aNiceKey # Specify the key as a trusted key. [DeviceB] sntp reliable authentication-keyid 10 # Specify Device A as the NTP server of Device B, and associate the server with key 10. [DeviceB] sntp unicast-server 1.0.1.11 authentication-keyid 10 4.
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 ?.
Severity value Level Description 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 Debug Debug message.
Default output rules for hidden logs Hidden logs can be output to the log host, log buffer, and the log file, but they cannot be filtered by source modules and severity levels. Table 9 shows the default output rules for hidden logs.
Output destination Format Example • HP format: • HP format: Timestamp Sysname %%vvModule/Level/Mnemon ic: Source; Content • unicom format: Log host Timestamp Hostip vvModule/Level/Serial_number: Content • cmcc format: Timestamp Sysname %vvModule/Level/Mnemonic : Source Content <190>Nov 24 16:22:21 2010 HP %%10SYSLOG/6/SYSLOG_RE START: -DevIP=1.1.1.1; System restarted –HP Comware Software. • unicom format: <189>Oct 13 16:48:08 2000 10.1.1.
Field Description Indicates that the information was generated by an HP device. %% (vendor ID) 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.
Timestamp parameters iso Description Example Timestamp format stipulated in ISO 8601. <189>2003-05-30T06:42:44 Sysname %%10FTPD/5/FTPD_LOGIN(l): User ftp (192.168.1.23) has logged in successfully. Only logs that are sent to a log host support this parameter. none no-year-date No timestamp is included. All logs support this parameter. 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.
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.
Step 8. (Optional.) Set the lowest level of logs that can be output to the monitor terminal. Command Remarks terminal logging level severity The default setting is 6 (informational). Outputting logs to a log host 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 outputting logs to a log host.
Saving logs to the log file By default, the log file feature saves logs from the log file buffer to the log file every 24 hours. You can adjust the saving interval or manually save logs to the log file. After saving logs into the log file, the system clears the log file buffer. The log file has a maximum capacity. When the capacity is reached, the system will replace earliest logs with new logs. To save logs to the log file: Step Command Remarks 1. Enter system view. system-view N/A 2.
Saving diagnostic logs to the diagnostic log file By default, the system saves diagnostic logs from the diagnostic log 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 into the diagnostic log file, the system clears the diagnostic log buffer. The diagnostic log file has a maximum capacity. When the capacity is reached, the system replaces earliest diagnostic logs with new logs.
Step Set the maximum size of the trace log file. 2. Command Remarks info-center trace-logfile quota size By default, the maximum size of the trace log file is 1 MB. Enabling synchronous information output The system log output interrupts ongoing configuration operations, obscuring previously input commands before the logs. Synchronous information output can show the previous input after log output.
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 specific 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.
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 16 Network diagram Configuration procedure # Enable the information center. system-view [Sysname] info-center enable # Disable log output to the console.
Configuration procedure Before the configuration, make sure the device and the log host can reach each other. (Details not shown.) 1. Configure the device: # Enable the information center. system-view [Device] info-center enable # Specify the log host 1.2.0.1/16 and specify local4 as the logging facility. [Device] info-center loghost 1.2.0.1 facility local4 # Disable log output to the log host.
Now, the device 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 device to output to the Linux log host 1.2.0.1/16 FTP logs that have a severity level of at least informational. Figure 18 Network diagram Configuration procedure Before the configuration, make sure the device and the log host can reach each other. (Details not shown.) 1.
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/Device/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.
Configuring SNMP This chapter provides an overview of the Simple Network Management Protocol (SNMP) and guides you through the configuration procedure. Overview 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.
Figure 20 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.
Configuring SNMPv1 or SNMPv2c basic parameters SNMPv1 and SNMPv2c settings are supported only in non-FIPS mode. To configure SNMPv1 or SNMPv2c basic parameters: Step 1. Enter system view. Command Remarks system-view N/A By default, the SNMP agent is disabled. The SNMP agent is enabled when you perform any command that begins with snmp-agent except for the snmp-agent calculate-password command. 2. (Optional.) Enable the SNMP agent. snmp-agent 3. (Optional.) Configure the system contact.
Step Command Remarks • (Method 1.) Create an SNMP community: snmp-agent community { read | write } [ simple | cipher ] community-name [ mib-view view-name ] [ acl acl-number ] • (Method 2.) Create an SNMPv1/v2c 8. Configure the SNMP access right. 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 ] b. snmp-agent usm-user { v1 | v2c } user-name group-name [ acl acl-number ] 9.
Table 15 Basic security setting requirements for different security models Security model Authentication with privacy Security model keyword for the group Security key settings for the user Remarks privacy Authentication key, privacy key If the authentication key or the privacy key is not configured, SNMP communication will fail.
Step 8. Command (Optional.) Create or update a MIB view. snmp-agent mib-view { excluded | included } view-name oid-tree [ mask mask-value ] Remarks 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.
Step Command Remarks • In non-FIPS mode: 12. Create an SNMPv3 user.
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 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.
Step 4. 5. 6. Command Remarks (Optional.) Enable extended linkUp/linkDown notifications. snmp-agent trap if-mib link extended By default, the SNMP agent sends standard linkup/linkDown notifications. (Optional.) Configure the notification queue size. snmp-agent trap queue-size size By default, the notification queue can hold 100 notification messages. (Optional.) Configure the notification lifetime. snmp-agent trap life seconds The default notification lifetime is 120 seconds.
Network requirements As shown in Figure 21, 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 21 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.
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 22, the NMS (1.1.1.
[Agent] snmp-agent sys-info contact Mr.Wang-Tel:3306 [Agent] snmp-agent sys-info location telephone-closet,3rd-floor # Enable notifications, specify the NMS at 1.1.1.2 as a trap destination, and set the username to managev3user for the traps. [Agent] snmp-agent trap enable [Agent] snmp-agent target-host trap address udp-domain 1.1.1.2 params securityname managev3user v3 privacy 2. Configure the SNMP NMS: { Specify SNMPv3. { Create the SNMPv3 user managev3user.
SNMP Version = V3 Community = managev3user Command = Trap 72
Configuring port mirroring The port mirroring feature is available on both Layer 2 and Layer 3 Ethernet interfaces. The term "interface" in this chapter collectively refers to these two types of interfaces. You can use the port link-mode command to configure an Ethernet port as a Layer 2 or Layer 3 interface (see Layer 2—LAN Switching Configuration Guide).
Reflector port, egress port, and remote probe VLAN A reflector port, remote probe VLAN, and an egress port are used for Layer 2 remote port mirroring. The remote probe VLAN specially transmits mirrored packets to the destination device. Both the reflector port and egress port reside on a source device and send mirrored packets to the remote probe VLAN.
groups. The mirroring group that contains the mirroring source or the mirroring destination is called a "remote source group" or "remote destination group," respectively. The devices between the source devices and destination device are intermediate devices. In Layer 2 remote port mirroring, the mirroring source and the mirroring destination are located on different devices on a same Layer 2 network. The source device copies packets received on the source port to the egress port.
Tasks at a glance (Required.) Perform at least one of the following tasks: 2. { Configuring source ports for the local mirroring group { Configuring source CPUs for the local mirroring group (Required.) Configuring the monitor port for the local mirroring group 3. 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 group exists.
Step Configure the port as a source port for the specified local mirroring group. 3. Command Remarks mirroring-group group-id mirroring-port { both | inbound | outbound } By default, a port does not serve as a source port for any local mirroring group. Configuring source CPUs for the local mirroring group A mirroring group can contain multiple source CPUs. To configure source CPUs for a local mirroring group: Step Command Remarks 1. Enter system view. system-view N/A 2.
Step Command Remarks 1. Enter system view. system-view N/A 2. Configure the monitor port for the specified local mirroring group. mirroring-group group-id monitor-port interface-type interface-number By default, no monitor port is configured for a local mirroring group. To configure 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.
• A mirroring group can contain multiple source ports. • To make sure the port mirroring function operates correctly, do not assign a source port to the remote probe VLAN. • If you have already configured a reflector port for a remote source group, you can no longer configure an egress port for it. • A VLAN can serve as the remote probe VLAN for only one remote source group. HP recommends that you use the remote probe VLAN for port mirroring exclusively.
Configuring Layer 2 remote port mirroring Configuring Layer 2 remote port mirroring is to configure remote mirroring groups. When doing this, configure a remote source group on the source device and a cooperating remote destination group on the destination device. If intermediate devices exist, configure the intermediate devices to allow the remote probe VLAN to pass through.
• Do not enable the spanning tree feature on the monitor port. • When a Layer 2 aggregate interface is configured as the monitor port, do not configure its member ports as source ports. • Use a monitor port only for port mirroring to make sure the data monitoring device receives and analyzes only the mirrored traffic rather than a mix of mirrored traffic and correctly forwarded traffic. • A mirroring group must contain only one monitor port.
Step Command Remarks 1. Enter system view. system-view N/A 2. Configure the remote probe VLAN for the specified remote destination group. mirroring-group group-id remote-probe vlan vlan-id By default, no remote probe VLAN is configured for a remote destination group. Assigning the monitor port to the remote probe VLAN Step Command 1. Enter system view. system-view 2. Enter the interface view of the monitor port.
Step Configure source ports for the specified remote source group. 2. Command Remarks mirroring-group group-id mirroring-port interface-list { both | inbound | outbound } By default, no source port is configured for a remote source group. To configure a source port for a remote source group 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.
Step Command Remarks 1. Enter system view. system-view N/A 2. Configure the egress port for the specified remote source group. mirroring-group group-id monitor-egress interface-type interface-number By default, no egress port is configured for a remote source group. To configure the egress port for a remote source group 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.
Port mirroring configuration examples Local port mirroring configuration example (in source port mode) Network requirements As shown in Figure 25, configure local port mirroring in source port mode to enable the server to monitor the bidirectional traffic of the marketing department and the technical department. Figure 25 Network diagram Configuration procedure # Create local mirroring group 1.
FortyGigE1/0/1 Both FortyGigE1/0/2 Both Monitor port: FortyGigE1/0/3 The output shows that you can monitor all packets received and sent by the marketing department and the technical department on the server. Local port mirroring configuration example (in source CPU mode) Network requirements As shown in Figure 26, FortyGigE 1/0/1 and FortyGigE 1/0/2 are located on the card in slot 1.
[Device] display mirroring-group all Mirroring group 1: Type: Local Status: Active Mirroring CPU: Slot 1 Both Monitor port: FortyGigE1/0/3 The output shows that you can monitor on the server all packets received and sent by the marketing department and the technical department and processed by the CPU of the card in slot 1 of the device. Local port mirroring with multiple monitor ports configuration example Network requirements As shown in Figure 27, Dept. A, Dept. B, and Dept.
# Create VLAN 10 and assign the three ports (FortyGigE 1/0/11 through FortyGigE 1/0/13) connecting the three data monitoring devices to VLAN 10. [DeviceA] vlan 10 [DeviceA-vlan10] port fortygige 1/0/11 to fortygige 1/0/13 [DeviceA-vlan10] quit # Configure VLAN 10 as the remote probe VLAN of remote source group 1.
[DeviceC] mirroring-group 2 remote-probe vlan 2 [DeviceC] interface fortygige 1/0/2 [DeviceC-FortyGigE1/0/2] mirroring-group 2 monitor-port [DeviceC-FortyGigE1/0/2] undo stp enable [DeviceC-FortyGigE1/0/2] port access vlan 2 [DeviceC-FortyGigE1/0/2] quit 2. Configure Device B (the intermediate device): # Create VLAN 2, which is to be configured as the remote probe VLAN. system-view [DeviceB] vlan 2 # Disable MAC address learning for VLAN 2.
Verifying the configuration # Display information about all mirroring groups on Device C. [DeviceC] display mirroring-group all Mirroring group 2: Type: Remote destination Status: Active Monitor port: FortyGigE1/0/2 Remote probe VLAN: 2 # Display information about all mirroring groups on Device A.
Configuring traffic mirroring The traffic mirroring feature is available on both Layer 2 and Layer 3 Ethernet interfaces. The term "interface" in this chapter collectively refers to these two types of interfaces. You can use the port link-mode command to configure an Ethernet port as a Layer 2 or Layer 3 interface (see Layer 2—LAN Switching Configuration Guide). Local traffic mirroring Local traffic mirroring copies the specified packets to the specified destination for packet analyzing and monitoring.
Step Command Remarks 2. Create a class and enter class view. traffic classifier tcl-name [ operator { and | or } ] By default, no traffic class exists. 3. Configure match criteria. if-match match-criteria By default, no match criterion is configured in a traffic class. Configuring a traffic behavior Step Command Remarks 1. Enter system view. system-view N/A 2. Create a traffic behavior and enter traffic behavior view.
Applying a QoS policy Applying a QoS policy to an interface By applying a QoS policy to an interface, you can mirror the traffic in a specific direction on the interface. A policy can be applied to multiple interfaces, but in one direction (inbound or outbound) of an interface, only one policy can be applied. To apply a QoS policy to an interface: Step Command 1. Enter system view. system-view 2. Enter interface view. interface interface-type interface-number 3. Apply a policy to the interface.
Traffic mirroring configuration example Network requirements As shown in Figure 29, different departments of a company use IP addresses on different subnets. The marketing and technical departments use the IP addresses on subnets 192.168.1.0/24 and 192.168.2.0/24, respectively. The working hour of the company is from 8:00 to 18:00 on weekdays. Configure traffic mirroring so that the server can monitor the following traffic: • All traffic that the technical department sends to access the Internet.
# Create traffic behavior tech_b, configure the action of mirroring traffic to port FortyGigE 1/0/3. [DeviceA] traffic behavior tech_b [DeviceA-behavior-tech_b] mirror-to interface fortygige 1/0/3 [DeviceA-behavior-tech_b] quit # Create QoS policy tech_p, and associate traffic class tech_c with traffic behavior tech_b in the QoS policy.
Configuring sFlow Sampled Flow (sFlow) is a traffic monitoring technology. As shown in Figure 30, the sFlow system involves an sFlow agent embedded in a device and a remote sFlow collector. The sFlow agent collects interface counter information and packet information and encapsulates the sampled information in sFlow packets.
Tasks at a glance Perform at least one of the following tasks: • Configuring flow sampling • Configuring counter sampling Configuring the sFlow agent and sFlow collector information Step 1. 2. Enter system view. (Optional.) Configure an IP address for the sFlow agent. Command Remarks system-view N/A By default, no IP address is configured for the sFlow agent. The device periodically checks whether the sFlow agent has an IP address.
Step Command Remarks The default setting is random. 3. (Optional.) Set the flow sampling mode. sflow sampling-mode { determine | random } 4. Enable flow sampling and specify the number of packets out of which flow sampling samples a packet on the interface. sflow sampling-rate rate By default, flow sampling samples no packet. (Optional.) Set the maximum number of bytes of a packet (starting from the packet header) that flow sampling can copy.
sFlow configuration example Network requirements As shown in Figure 31, configure flow sampling in random mode and counter sampling on FortyGigE 1/0/1 of the device to monitor traffic on the port. Configure the device to send sampled information in sFlow packets through FortyGigE 1/0/3 to the sFlow collector. Figure 31 Network diagram Configuration procedure 1. Configure the IP addresses and subnet masks for interfaces, as shown in Figure 31. (Details not shown.) 2.
Verifying the configuration # Display the sFlow configuration and operation information. [Sysname-FortyGigE1/0/1] display sflow sFlow datagram version: 5 Global information: Agent IP: 3.3.3.1(CLI) Source address: Collector information: ID IP Port Aging Size VPN-instance Description 1 3.3.3.
4. Verify that the length of an sFlow packet is greater than the length of the sFlow packet header plus the number of bytes (HP recommends the default) that flow sampling can copy per packet.
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.
• A UDP jitter or a voice operation sends a specific number of probe packets. The number of probe packets is configurable with the probe packet-number command. • An FTP operation uploads or downloads a file. • An HTTP operation gets a Web page. • A DHCP operation gets an IP address through DHCP. • A DNS operation translates a domain name to an IP address. • An ICMP echo operation sends an ICMP echo request. • A UDP echo operation sends a UDP packet.
Table 16 describes the relationships between performance metrics and NQA operation types.
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. • TCP listening service: Configure a TCP or UDP listening service. 3. 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 specify the ToS value in the IP packet header of NQA probe packets. The default ToS value is 0.
Configuring the ICMP echo operation The ICMP echo operation measures the reachability of a destination device. It has the same function as the ping command, but provides more output information. In addition, if multiple paths exist between the source and destination devices, you can specify the next hop for the ICMP echo operation. To configure the ICMP echo operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view.
NOTE: The switch does not support functioning as a DHCP server. To configure the DHCP operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. nqa entry admin-name operation-tag By default, no NQA operation is created. 3. Specify the DHCP type and enter its view. type dhcp N/A 4. Specify the destination IP address of DHCP packets. By default, no destination IP address is specified.
Step Command Remarks 3. Specify the DNS type and enter its view. type dns N/A 4. Specify the IP address of the DNS server as the destination address of DNS packets. destination ip ip-address By default, no destination IP address is specified. Specify the domain name that needs to be translated. resolve-target domain-name By default, no domain name is specified. 5.
Step Command Remarks 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. 10. Set the data transmission mode. By default, no file is specified. filename file-name This step is required if you perform the put operation.
Step Command 11. (Optional.) Specify the content of a GET request for the HTTP operation. Enter or paste the content. 12. Save the input and exit to HTTP operation view. quit Remarks By default, no contents are specified. This step is required for the raw operation. 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.
Step Command Remarks 7. Specify the payload size in each UDP packet. data-size size The default setting is 100 bytes. 8. Specify the string to be filled in the payload of each UDP packet. data-fill string The default setting is the hexadecimal number 00010203040506070809. 9. Specify the number of UDP packets sent in one UDP jitter operation. probe packet-number packet-number The default setting is 10. 10. Configure the interval for sending UDP packets.
Step Command Remarks By default, no source IP address is specified. 6. (Optional.) Specify the source IP address of SNMP packets. source ip ip-address The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no SNMP packets can be sent out. Configuring the TCP operation The TCP operation measures the time for the NQA client to establish a TCP connection to a specific 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 operation is created. 3.
1. The NQA client sends voice packets of G.711 A-law, G.711 μ-law or G.729 A-law codec type at a specific interval to the destination device (NQA server). 2. The destination device takes a time stamp to each voice packet it receives and sends it back to the source. 3. Upon receiving the packet, the source device calculates the jitter and one-way delay based on the time stamp.
Step Command Remarks By default, no source IP address is specified. 8. (Optional.) Specify the source IP address of voice packets. source ip ip-address 9. (Optional.) Specify the source port number of voice packets. source port port-number By default, no source port number is specified. 10. Specify the payload size in each voice packet. data-size size By default, the voice packet size depends on the codec type. The default packet size is 172 bytes for G.711A-law and G.
Step Command Remarks By default, no source IP address is specified. (Optional.) Specify the source IP address of probe packets. 5. source ip ip-address The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out. Configuring the path jitter operation The path jitter operation measures the jitter, negative jitters, and positive jitters from the NQA client to each hop on the path to the destination.
Step Command Remarks 10. 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. By default, no LSR path is specified. 11. (Optional.) Specify an LSR path. lsr-path ip-address&<1-8> 12. (Optional.) Perform the path jitter operation on destination only.
Step Command Remarks The default setting is 20. 8. (Optional.) Specify the TTL for probe packets. ttl value This command is not available for the DHCP and path jitter operations. 9. (Optional.) Specify the ToS value in the IP packet header of probe packets. tos value The default setting is 0. 10. (Optional.) Enable the routing table bypass function. route-option bypass-route By default, the routing table bypass function is disabled.
• accumulate—If the total number of times that the monitored performance metric is out of the specified value range reaches or exceeds the specified threshold, a threshold violation occurs. • consecutive—If the number of consecutive times that the monitored performance metric is out of the specified value range reaches or exceeds the specified threshold, a threshold violation occurs.
Step Command Remarks • Monitor the operation duration (not supported in the UDP jitter and voice operations): reaction item-number checked-element probe-duration threshold-type { accumulate accumulate-occurrences | average | consecutive consecutive-occurrences } threshold-value upper-threshold lower-threshold [ action-type { none | trap-only } ] • Monitor failure times (not supported in the UDP jitter and voice operations): reaction item-number checked-element probe-fail threshold-type { accumulate acc
Configuring the NQA statistics collection function NQA collects statistics for operations completed within a specific period. The statistics forms a statistics group. A statistics group is generated after an operation is completed. To view information about the statistics groups, use the display nqa statistics command. A statistics group is deleted when its hold time expires. When the maximum number of statistics groups is reached, to save a new statistics group, the oldest statistics group is deleted.
Step Command Remarks Create an NQA operation and enter NQA operation view. nqa entry admin-name operation-tag By default, no NQA operation is created. 3. Enter NQA operation type view. type { dhcp | dlsw | dns | ftp | http | icmp-echo | snmp | tcp | udp-echo } The UDP jitter, path jitter, and voice operations do not support the saving of history records function. 4. Enable the saving of history records for the NQA operation. history-record enable By default, this feature is not enabled.
Configuring the ICMP template A feature that uses the ICMP template creates and starts the ICMP echo operation to measure the reachability of a destination device. 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 N/A 3. (Optional.) Specify the destination IP address of the operation. destination ip ip-address By default, no destination IP address is configured. 4.
Step Command Remarks 3. (Optional.) Specify the DNS server's IP address. destination ip ip-address By default, the IP address of the DNS server is not specified. 4. Configure the destination port number for the operation. destination port port-number By default, the destination port number is 53. 5. Specify the domain name that needs to be translated. resolve-target domain-name By default, no domain name is specified. 6. Configure the domain name resolution type. resolve-type A 7.
Step 5. 6. Specify the string to be filled in the payload of each request. (Optional.) Configure the expected data. Command Remarks data-fill string The default setting is the hexadecimal number 00010203040506070809. By default, no expected data is configured. expect data expression [ offset number ] This command takes effect only when you configure the data-fill command.
Step Command Remarks This step is required for the raw operation. 7. (Optional.) Enter raw request view. raw-request 8. (Optional.) Enter or paste the content of the GET request for the HTTP operation. N/A (Optional.) Save the input and exit to HTTP template view. quit N/A 10. (Optional.) Configure the expected status codes. expect status status-list By default, no expected status code is configured. 11. (Optional.) Configure the expected data.
Configuring optional parameters for the NQA template Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA template and enter its view. nqa template { dns | ftp | http | icmp | tcp } name N/A 3. Configure a description. description text By default, no description is configured. 4. Specify the interval at which the NQA operation repeats. frequency interval If the operation is not completed when the interval expires, the next operation does not start. 5.
Task Command Display NQA server status. display nqa server status NQA configuration examples ICMP echo operation configuration example Network requirements As shown in Figure 34, configure and schedule an ICMP echo operation from the NQA client Device A to Device B through Device C to test the round-trip time. Figure 34 Network diagram Device C 10.1.1.2/24 10.2.2.1/24 NQA client 10.1.1.1/24 10.2.2.2/24 10.3.1.1/24 10.4.1.2/24 Device A Device B 10.3.1.2/24 10.4.1.
# Specify the probe timeout time for the ICMP echo operation as 500 milliseconds. [DeviceA-nqa-admin-test1-icmp-echo] probe timeout 500 # Configure the ICMP echo operation to repeat at an interval of 5000 milliseconds. [DeviceA-nqa-admin-test1-icmp-echo] frequency 5000 # Enable saving history records and configure the maximum number of history records that can be saved as 10.
DHCP operation configuration example Network requirements As shown in Figure 35, configure and schedule a DHCP operation to test the time required for Switch A to obtain an IP address from the DHCP server (Switch B). Figure 35 Network diagram Configuration procedure # Create a DHCP operation to be performed to the destination IP address 10.1.1.2. system-view [SwitchA] nqa entry admin test1 [SwitchA-nqa-admin-test1] type dhcp [SwitchA-nqa-admin-test1-dhcp] destination ip 10.1.1.
DNS operation configuration example Network requirements As shown in Figure 36, configure a DNS operation to test whether Device A can translate the domain name host.com into an IP address through the DNS server, and test the time required for resolution. Figure 36 Network diagram Configuration procedure # Assign each interface an IP address. (Details not shown.) # Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) # Create a DNS operation.
[DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test) history records: Index Response Status Time 1 62 Succeeded 2011-11-10 10:49:37.3 The output shows that Device A uses 62 milliseconds to translate domain name host.com into an IP address. FTP operation configuration example Network requirements As shown in Figure 37, configure an FTP operation to test the time required for Device A to upload a file to the FTP server.
# After the FTP operation runs for a period of time, stop the operation. [DeviceA] undo nqa schedule admin test1 # Display the most recent results of the FTP operation. [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 173/173/173 Square-Sum of round trip time: 29929 Last succeeded probe time: 2011-11-22 10:07:28.
# Configure the HTTP operation to get data from the HTTP server. By default, the HTTP operation type is get. [DeviceA-nqa-admin-test1-http] operation get # Configure the operation to use HTTP version 1.0. By default, the HTTP operation uses version 1.0. [DeviceA-nqa-admin-test1-http] version v1.0 # Enable the saving of history records. [DeviceA-nqa-admin-test1-http] history-record enable [DeviceA-nqa-admin-test1-http] quit # Start the HTTP operation.
Configuration procedure 1. Assign each interface an IP address. (Details not shown.) 2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) 3. Configure Device B: # Enable the NQA server. system-view [DeviceB] nqa server enable # Configure a listening service to listen on the IP address 10.2.2.2 and UDP port 9000. [DeviceB] nqa server udp-echo 10.2.2.2 9000 4. Configure Device A: # Create a UDP jitter operation.
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 de
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 40, configure an SNMP operation to test the time the NQA client uses to get a value from the SNMP agent. Figure 40 Network diagram Configuration procedure 1.
[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 50/50/50 Square-Sum of round trip time: 2500 Last succeeded probe time: 2011-11-22 10:24:41.1 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 # Display the history records of the SNMP operation.
# Configure 10.2.2.2 as the destination IP address and port 9000 as the destination port. [DeviceA-nqa-admin-test1-tcp] destination ip 10.2.2.2 [DeviceA-nqa-admin-test1-tcp] destination port 9000 # Enable the saving of history records. [DeviceA-nqa-admin-test1-tcp] history-record enable [DeviceA-nqa-admin-test1-tcp] quit # Start the TCP operation. [DeviceA] nqa schedule admin test1 start-time now lifetime forever # After the TCP operation runs for a period of time, stop the operation.
2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) 3. Configure Device B: # Enable the NQA server. system-view [DeviceB] nqa server enable # Configure a listening service to listen on the IP address 10.2.2.2 and UDP port 8000. [DeviceB] nqa server udp-echo 10.2.2.2 8000 4. Configure Device A: # Create a UDP echo operation.
Voice operation configuration example Network requirements As shown in Figure 43, configure a voice operation to test jitters between Device A and Device B. Figure 43 Network diagram Configuration procedure 1. Assign each interface an IP address. (Details not shown.) 2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) 3. Configure Device B: # Enable the NQA server.
Failures due to other errors: 0 Packets out of sequence: 0 Packets arrived late: 0 Voice results: RTT number: 1000 Min positive SD: 1 Min positive DS: 1 Max positive SD: 204 Max positive DS: 1297 Positive SD number: 257 Positive DS number: 259 Positive SD sum: 759 Positive DS sum: 1797 Positive SD average: 2 Positive DS average: 6 Positive SD square-sum: 54127 Positive DS square-sum: 1691967 Min negative SD: 1 Min negative DS: 1 Max negative SD: 203 Max negative DS: 1297 Negative SD number:
Positive SD number: 1030 Positive DS number: 1024 Positive SD sum: 4363 Positive DS sum: 5423 Positive SD average: 4 Positive DS average: 5 Positive SD square-sum: 497725 Positive DS square-sum: 2254957 Min negative SD: 1 Min negative DS: 1 Max negative SD: 360 Max negative DS: 1297 Negative SD number: 1028 Negative DS number: 1022 Negative SD sum: 1028 Negative DS sum: 1022 Negative SD average: 4 Negative DS average: 5 Negative SD square-sum: 495901 Negative DS square-sum: 5419 One way
[DeviceA] nqa schedule admin test1 start-time now lifetime forever # After the DLSw operation runs for a period of time, stop the operation. [DeviceA] undo nqa schedule admin test1 # Display the most recent results of the DLSw operation. [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 19/19/19 Square-Sum of round trip time: 361 Last succeeded probe time: 2011-11-22 10:40:27.
[DeviceA-nqa-admin-test1] type path-jitter [DeviceA-nqa-admin-test1-path-jitter] destination ip 10.2.2.2 # Configure the path jitter operation to repeat at an interval of 10000 milliseconds. [DeviceA-nqa-admin-test1-path-jitter] frequency 10000 [DeviceA-nqa-admin-test1-path-jitter] quit # Start the path jitter operation. [DeviceA] nqa schedule admin test1 start-time now lifetime forever # After the path jitter operation runs for a period of time, stop the operation.
Positive jitter number: 6 Min/Max/Average positive jitter: 1/9/4 Sum/Square-Sum positive jitter: 25/173 Negative jitter number: 3 Min/Max/Average negative jitter: 2/10/6 Sum/Square-Sum positive jitter: 19/153 NQA collaboration configuration example Network requirements As shown in Figure 46, configure a static route to Switch C with Switch B as the next hop on Switch A. Associate the static route, a track entry, and an ICMP operation to monitor the state of the static route.
4. On Switch A, create track entry 1, and associate it with reaction entry 1 of the NQA operation. [SwitchA] track 1 nqa entry admin test1 reaction 1 Verifying the configuration # On Switch A, display information about all the track entries.
# Display brief information about active routes in the routing table on Switch A. [SwitchA] display ip routing-table Destinations : 12 Routes : 12 Destination/Mask Proto 0.0.0.0/32 10.2.1.0/24 Pre Cost NextHop Interface Direct 0 0 127.0.0.1 InLoop0 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.
# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) # Create ICMP template icmp and specify 10.2.2.2 as the destination IP address. system-view [DeviceA] nqa template icmp icmp [DeviceA-nqatplt-icmp-icmp] destination ip 10.2.2.2 # Set the probe timeout time for the ICMP echo operation to 500 milliseconds. [DeviceA-nqatplt-icmp-icmp] probe timeout 500 # Configure the ICMP echo operation to repeat at an interval of 3000 milliseconds.
[DeviceA-nqatplt-dns-dns] reaction trigger probe-pass 2 # If the number of consecutive probe failures reaches 2, the operation fails. [DeviceA-nqatplt-dns-dns] reaction trigger probe-fail 2 TCP template configuration example Network requirements As shown in Figure 49, configure a TCP template for a feature to perform the TCP operation to test whether Device A can establish a TCP connection to Device B and process the server's response. Figure 49 Network diagram Configuration procedure 1.
Figure 50 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. system-view [DeviceA] nqa template http http # Specify the URL of the server. [DeviceA-nqatplt-http-http] url http://10.2.2.2/index.htm # Configure the HTTP operation to get data from the HTTP server. By default, the HTTP operation type is get.
# Specify the URL of the FTP server. [DeviceA-nqatplt-ftp-ftp] url ftp://10.2.2.2 # Specify 10.1.1.1 as the source IP address. [DeviceA-nqatplt-ftp-ftp] source ip 10.1.1.1 # Configure the device to upload file config.txt to the FTP server. [DeviceA-nqatplt-ftp-ftp] operation put [DeviceA-nqatplt-ftp-ftp] filename config.txt # Specify the username for the FTP server login as admin. [DeviceA-nqatplt-ftp-ftp] username admin # Specify the password for the FTP server login as systemtest.
Configuring NETCONF Overview Network Configuration Protocol (NETCONF) is an XML-based network management protocol with good 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.
NETCONF message format NETCONF 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. 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.
How to use NETCONF You can use NETCONF to manage and configure the device by using the methods in Table 18.
• RFC 5539, NETCONF over Transport Layer Security (TLS) • RFC 6241, Network Configuration Protocol 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 (see Security Configuration Guide) and non-FIPS mode. NETCONF configuration task list Task at a glance (Optional.) Enabling NETCONF over SOAP (Required.) Establishing a NETCONF session (Optional.
Step Command Remarks • Enable NETCONF over SOAP Enable NETCONF over SOAP. 2. over HTTP (not available in FIPS mode): netconf soap http enable By default, NETCONF over SOAP is disabled. • Enable NETCONF over SOAP over HTTPS: netconf soap https enable Establishing a NETCONF session A client must send a hello message to a device and finishing capabilities exchange before the device process other requests from the client. The device supports up to five NETCONF sessions.
Where, capability-set represents the capabilities supported by the client. Use a pair of and 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.
If the subscription fails, the device returns an error message in the following format: error-type error-tag error-severity error-message For more information about error messages, see RFC 4741.
# If fan 1 on the device encounters problems, the device sends the following text to the client that has subscribed to all events: 2011-01-04T12:30:46 PAGE 168 After receiving the lock request, the device returns a response in the following format if the lock operation is successful: Unlocking the configuration # Copy the following text to the client to unlock the configuration: PAGE 169 Verifying the configuration If the client receives the following response, the lock operation is successful: If another client sends a lock request, the device returns the following response:
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 exists: • You do not specify the count attribute. • The number of matched data entries is less than the value of the count attribute.
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:
Performing the edit-config operation The edit-config operation supports the following operation attributes: merge, create, replace, remove, delete, default-operation, error-option, and test-option. For more information about these attributes, see "Appendix A Supported NETCONF operations." # Copy the following text to perform the operation. PAGE 173 Verifying the configuration If the client receives the following text, the get-config operation is successful: PAGE 174 HP +11:44 beijing
Syslog configuration data retrieval example Network requirements Retrieve configuration data for the Syslog module. Configuration procedure # Enter XML view. xml # Exchange capabilities. urn:ietf:params:netconf:base:1.
120 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. xml # Exchange capabilities. urn:ietf:params:netconf:base:1.
3 Ten-GigabitEthernet1/0/2 XGE1/0/2 3 22 6 Ten-GigabitEthernet 1/0/2 Interface 2 2 0 100000 3 1 Exam
512 Verifying the configuration If the client receives the following text, the edit-config operation is successful: Saving, rolling back, and loading the configuration Use NETCONF to save, roll back, or load the configuration.
After receiving the rollback request, the device returns a response in the following format if the rollback operation is successful: Loading the configuration After you perform the load operation, the loaded configurations are merged into the current configuration as follows: • New configurations are directly loaded.
urn:ietf:params:netconf:base:1.0 # Save the configuration of the device to the configuration file my_config.cfg. my_config.cfg Verifying the configuration If the client receives the following response, the save operation is successful:
# 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. PAGE 181Operation Operator Remarks 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 of which the CPU usage is more than 50%. PAGE 182
Verifying the configuration If the client receives the following text, the operation is successful. PAGE 183Example 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. xml # Exchange capabilities. urn:ietf:params:netconf:base:1.
7241 NULL0 7243 Register-Tunnel0 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: PAGE 185Configuration procedure # Enter XML view. xml # Exchange capabilities. urn:ietf:params:netconf:base:1.0 # Copy the following text to the client to execute the display current-configuration command. PAGE 186# Copy the following message to the client to retrieve NETCONF session information from the device: After receiving the get-sessions request, the device returns a response in the following format if the get-sessions operation is successful: PAGE 187
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.
# Terminate the session with session ID 2. 2 Verifying the configuration If the client receives the following text, the NETCONF session with session ID 2 has been terminated. The client with session ID 2 has returned from XML view to user view: PAGE 189Appendix Appendix A Supported NETCONF operations Table 20 lists the NETCONF operations available with Comware V7. Table 20 NETCONF operations Operation Description XML example To retrieve device configuration and state information for the Syslog module: get Retrieves device configuration and state information. PAGE 190Operation Description XML example To retrieve non-default configuration data for the interface table: get-config Retrieves the non-default configuration data. If non-default configuration data does not exist, the device returns a response with empty data. PAGE 191Operation Description XML example To retrieve non-default configuration for all interfaces: 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. PAGE 192Operation Description XML example 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 edit-config: create creation and the specified target does not exist, the operation creates and then configures the target. The XML data format is the same as the edit-config message with the merge attribute. Change the operation attribute from merge to create.
Operation Description XML example 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. edit-config: delete • 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.
Operation Description XML example 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 element takes effect only once.
Operation Description XML example To issue the configuration for two interfaces with the error-option element value as continue-on-error: continue-on-error Determines the action to take in case of a configuration error. The error-option element has one of the following values: PAGE 196Operation Description XML example To issue the configuration for an interface for test purposes: 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 edit-config: test-option validation test before attempting to set. If the validation test fails, the edit-config operation is not performed.
Operation lock Description XML example Locks the configuration data that can be changed by the edit-config operation. Other configurations are not limited by the lock operation. To lock the configuration: This lock operation locks only the configurations made through NETCONF sessions, rather than those through other protocols, for example, SNMP. PAGE 198Operation Description XML example Executes CLI operations. A request message encloses commands in the element, and a response message encloses the command output in the element. CLI NETCONF supports the following views: To execute a command in other views, specify the command for entering the specified view, and then the desired command. load PAGE 199Support and other resources Contacting HP For worldwide technical support information, see the HP support website: http://www.hp.
Conventions This section describes the conventions used in this documentation set. Command conventions Convention Description Boldface Bold text represents commands and keywords that you enter literally as shown. Italic Italic text represents arguments that you replace with actual values. [] Square brackets enclose syntax choices (keywords or arguments) that are optional. { x | y | ... } Braces enclose a set of required syntax choices separated by vertical bars, from which you select one.
Network topology icons Represents a generic network device, such as a router, switch, or firewall. Represents a routing-capable device, such as a router or Layer 3 switch. Represents a generic switch, such as a Layer 2 or Layer 3 switch, or a router that supports Layer 2 forwarding and other Layer 2 features. Represents an access controller, a unified wired-WLAN module, or the switching engine on a unified wired-WLAN switch. Represents an access point.
Index A NMM NTP multicast association mode, 9, 15, 31 access control NMM NTP symmetric active/passive association mode, 9, 14, 28 NMM NTP access control rights configuration, 16 authenticating NMM NTP, 12 NMM NTP peer ACL, 11 NMM NTP broadcast authentication, 20 NMM NTP query ACL, 11 NMM NTP broadcast mode with authentication, 36 NMM NTP security, 11 NMM NTP client/server mode authentication, 16 NMM NTP server ACL, 11 NMM NTP client/server mode with authentication, 34 NMM NTP synchronization A
NMM NQA client DLSw operation, 115 local port mirroring multiple monitor ports, 87 NMM NQA client DNS operation, 107 NMM information center, 43, 48 NMM NQA client FTP operation, 108 NMM information center trace log file, 52 NMM NQA client FTP template, 126 NMM Layer 2 remote port mirroring, 80, 80, 88 NMM NQA client history record save, 121 NMM local port mirroring, 75 NMM NQA client HTTP operation, 109 NMM local port mirroring (source CPU mode), 86 NMM NQA client HTTP template, 125 NMM local p
NMM port mirroring remote destination group monitor port, 80 NMM NQA FTP operation, 132 NMM NQA FTP template, 151 NMM port mirroring remote destination group remote probe VLAN, 81 NMM NQA HTTP operation, 133 NMM NQA HTTP template, 150 NMM remote port mirroring destination group, 80 NMM NQA ICMP echo operation, 128 NMM remote port mirroring source group, 82 NMM NQA ICMP template, 148 NMM remote port mirroring source group egress port, 83 NMM NQA path jitter operation, 144 NMM NQA server, 104 NMM re
NMM information center log output (UNIX log host), 55 NMM traffic mirroring configuration, 91 creating NMM local port mirroring local group, 76 NMM information center system log types, 43 NMM port mirroring remote destination group, 80 NMM Layer 2 remote port mirroring, 80 NMM Layer 2 remote port mirroring configuration, 80, 88 NMM port mirroring remote source group, 82 NMM local port mirroring configuration, 75 criteria NMM local port mirroring configuration (source CPU mode), 86 local traffic mir
NMM port mirroring remote source group source CPU, 83 NMM NQA client DNS template, 123 NMM port mirroring remote source group source ports, 82 NMM NQA DNS template configuration, 149 NMM SNMP configuration, 59 SNMP basic parameter configuration, 60 SNMP MIB, 59 SNMP notification configuration, 66 SNMP view-based MIB access control, 59 SNMPv1 basic parameter configuration, 61 SNMPv1 configuration, 68 NMM NQA DNS operation, 131 DSCP NMM NTP packet value configuration, 26 duplicate log suppression, 53 dyn
NMM NETCONF capabilities, 157 hidden log (information center), 43 history F NMM NQA client history record save, 121 file NMM information center diagnostic log output destination, 52 NMM information center log output destination, 51 host NMM information center log output (log host), 50 SNMP agent notification, 66 HTTP NMM NETCONF over SOAP (HTTP-based), 156 filtering NMM NETCONF over SOAP (HTTPS-based), 156 NMM NETCONF data (conditional match), 176 NMM NQA, 102 NMM NETCONF data (regex match), 174
NMM NQA client TCP operation, 112 log output (monitor terminal), 49 log output (UNIX log host), 55 NMM NQA client TCP template, 124 log save to file, 51 NMM NQA client template optional parameters, 127 maintaining, 54 synchronous log output, 53 NMM NQA client threshold monitoring, 118 system information log types, 43 NMM NQA client UDP echo operation, 112 NMM NQA client UDP jitter operation, 110 system log destinations, 44 NMM NQA client voice operation, 113 system log formats, 45 NMM NQA client
NMM NETCONF configuration, 170, 171 NMM information center system log formats, 45 local NMM information center system log levels, 43 NMM information center trace log file, 52 configuring port mirroring multiple monitor ports, 87 NMM system information diagnostic log default output rules, 44 enabling port mirroring multiple monitor ports (remote probe VLAN), 78 NMM system information hidden log default output rules, 45 local clock as reference source, 26 NMM system information trace log default outp
over SOAP enable, 156 NMM NETCONF configuration data retrieval (Syslog module), 167 parameter value change, 169 NMM NETCONF data entry retrieval (interface table), 168 protocols and standards, 155 service operations, 162 module debugging switch, 5 session establishment, 157 monitor port session information retrieval, 178 configuring local port mirroring multiple monitor ports, 87 session termination, 180 supported operations, 182 monitor terminal NMM information center log output, 49 monitoring
NMM NQA client UDP jitter operation, 110 NMM traffic mirroring QoS policy application, 93 NMM NQA client voice operation, 113 NMM traffic mirroring QoS policy application (global), 93 NMM NQA client/Track collaboration function, 118 NMM traffic mirroring QoS policy application (interface), 93 NMM NQA server configuration, 104 NMM traffic mirroring QoS policy application (VLAN), 93 NMM NTP access control rights, 16 NMM NTP architecture, 8 NMM traffic mirroring QoS policy configuration, 92 NMM NTP a
information center log output (Linux log host), 57 NMM NQA SNMP operation, 137 NMM NQA TCP operation, 138 information center log output (log buffer), 50 NMM NQA TCP template configuration, 150 information center log output (log host), 50 NMM NQA UDP echo operation, 139 information center log output (monitor terminal), 49 NMM NQA UDP jitter operation, 134 information center log output (UNIX log host), 55 NMM NQA voice operation, 141 information center log save to file, 51 NMM NQA/Track collaborati
NQA threshold monitoring, 103 NETCONF session information retrieval, 178 NETCONF session termination, 180 NQA Track collaboration, 146 NETCONF supported operations, 182 NQA UDP echo operation, 139 NQA client DHCP operation, 106 NQA UDP jitter operation, 134 NQA client DLSw operation, 115 NQA voice operation, 141 NQA client DNS operation, 107 NQA/Track collaboration, 103 NQA client FTP operation, 108 NTP access control rights, 16 NQA client FTP template, 126 NTP architecture, 8 NQA client hist
SNMP Set operation, 60 sFlow configuration, 96, 96, 99 sFlow counter sampling configuration, 98 Notification operation (SNMP), 60 sFlow flow sampling configuration, 97 notifying SNMP agent notification, 66 SNMP basic parameter configuration, 60 NMM NETCONF event notification subscription, 158, 159 SNMP configuration, 59 SNMP agent notification, 66 SNMP framework, 59 SNMP Get operation, 60 SNMP notification configuration, 66 NQA client DHCP operation, 106 SNMP logging configuration, 65 SNMP MIB, 5
ICMP echo operation, 128 message source interface specification, 24 ICMP template configuration, 148 multicast association mode, 9 operation types, 102 multicast association mode configuration, 15, 31 path jitter operation, 144 multicast client configuration, 15 server configuration, 104 multicast mode authentication configuration, 22 SNMP operation, 137 multicast mode max number dynamic associations, 25 TCP operation, 138 multicast server configuration, 15 TCP template configuration, 150 opt
NMM traffic mirroring match criteria configuration, 91 NMM traffic mirroring QoS policy application, 93 system maintenance, 1 policy NMM traffic mirroring QoS policy application, 93 NMM traffic mirroring QoS policy application (global), 93 NMM traffic mirroring QoS policy application (global), 93 NMM traffic mirroring QoS policy application (interface), 93 NMM traffic mirroring QoS policy application (interface), 93 NMM traffic mirroring QoS policy application (VLAN), 93 NMM traffic mirroring QoS poli
configuring NMM local port mirroring group source CPUs, 77 local group source port, 76 local group source port configuration restrictions, 76 configuring NMM local port mirroring group source ports, 76 local mirroring configuration (source CPU mode), 86 configuring NMM local traffic mirroring, 91, 94 local mirroring configuration (source port mode), 85 configuring NMM NETCONF, 156 configuring NMM NQA, 104, 128 mirroring group, 73 configuring NMM NQA client DHCP operation, 106 monitor port to remote
configuring NMM NQA DNS template, 149 configuring NMM NTP multicast mode authentication, 22 configuring NMM NQA FTP operation, 132 configuring NMM NTP multicast server, 15 configuring NMM NQA FTP template, 151 configuring NMM NTP optional parameters, 24 configuring NMM NQA HTTP operation, 133 configuring NMM NQA HTTP template, 150 configuring NMM NTP packet DSCP value, 26 configuring NMM NQA ICMP echo operation, 128 configuring NMM NTP symmetric active/passive association mode, 14, 28 configuring
configuring SNMPv1 basic parameters, 61 loading NMM NETCONF configuration, 170, 171 configuring SNMPv2c, 68 locking NMM NETCONF configuration, 160, 161 configuring SNMPv2c agent notification, 66 maintaining NMM information center, 54 configuring SNMPv2c basic parameters, 61 outputting NMM information center logs to console, 49, 55 configuring SNMPv3, 70 outputting NMM information center logs to Linux log host, 57 configuring SNMPv3 agent notification, 66 configuring SNMPv3 basic parameters, 62 ou
remote destination group, 80 testing connectivity with ping, 1 troubleshooting NMM sFlow, 100 remote destination group creation, 80 troubleshooting NMM sFlow remote collector cannot receive packets, 100 remote destination group monitor port configuration, 80 unlocking NMM NETCONF configuration, 160, 161 remote destination group remote probe VLAN configuration, 81 protocols and standards remote source group, 82 NMM NETCONF, 153, 155 remote source group creation, 82 NMM NTP, 12 remote source group
NMM NTP client/server association mode, 27 NMM NTP broadcast client configuration, 14 NMM NTP client/server mode with authentication, 34 NMM NTP broadcast server configuration, 15 NMM NTP configuration, 7, 13 NMM SNTP configuration, 39, 39, 41 NMM NTP multicast server configuration, 15 NMM NTP multicast association mode, 31 NMM NTP symmetric active/passive association mode, 28 NMM SNTP NTP server specification, 39 service NMM NETCONF configuration data retrieval (all modules), 165 NMM SNTP configur
NTP server specification, 39 displaying settings, 68 framework, 59 SOAP Get operation, 60, 65 NMM NETCONF message format, 154 logging configuration, 65 NMM NETCONF over SOAP enable, 156 manager, 59 source MIB, 59, 59 MIB view-based access control, 59 NMM port mirroring, 73 specifying NMM NQA, 102 NMM NTP message source interface, 24 NMM NQA client SNMP operation, 111 NMM SNTP NTP server, 39 NMM NQA SNMP operation, 137 statistics notification configuration, 66 NMM NQA client statistics coll
NMM information center interface link up/link down log generation, 54 NMM NQA client template optional parameters, 127 NMM information center log destinations, 44 NMM NQA DNS template configuration, 149 NMM information center log levels, 43 NMM NQA FTP template configuration, 151 NMM information center log output (console), 49, 55 NMM NQA HTTP template configuration, 150 NMM information center log output (Linux log host), 57 NMM NQA TCP template configuration, 150 NMM information center log output
NMM sFlow counter sampling configuration, 98 UNIX NMM sFlow flow sampling configuration, 97 traffic mirroring NMM information center log host, 55 unlocking configuration, 91 local, 91 local configuration, 91, 94 match criteria configuration, 91 QoS policy application, 93 QoS policy application (global), 93 QoS policy application (interface), 93 NMM NETCONF configuration, 160, 161 V value NMM NETCONF parameter value change, 169 view-based MIB access control, 59 VLAN enabling port mirroring multiple moni
