HP MSR2000/3000/4000 Router Series Network Management and Monitoring Configuration Guide (V7) Part number: 5998-3999 Software version: CMW710-R0007P02 Document version: 6PW100-20130927
Legal and notice information © Copyright 2013 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
ICMP echo operation configuration example ···································································································· 34 DHCP operation configuration example ············································································································· 36 DNS operation configuration example ··············································································································· 37 FTP operation configuration example ·····························
Configuration Configuration Configuration Configuration example for NTP client/server mode with authentication ································································· 94 example for NTP broadcast mode with authentication ····································································· 96 example for MPLS VPN time synchronization in client/server mode ·············································· 98 example for MPLS VPN time synchronization in symmetric active/passive mode ··················
How to use NETCONF ······································································································································· 131 Protocols and standards ····································································································································· 131 FIPS compliance ··························································································································································· 131 NETCONF configu
Verifying the configuration ································································································································· 173 Configuring samplers ·············································································································································· 174 Creating a sampler ······················································································································································ 174 Display
Verifying the configurations ······························································································································· 198 Troubleshooting sFlow configuration ························································································································· 198 The remote sFlow collector cannot receive sFlow packets ·············································································· 198 Configuring the information center ··············
Support and other resources ·································································································································· 231 Contacting HP ······························································································································································ 231 Subscription service ············································································································································ 231 Relate
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.
Figure 1 Network diagram Configuration procedure # Use the ping command on Device A to test connectivity to Device C. Ping 1.1.2.2 (1.1.2.2): 56 data bytes, press escape sequence to break 56 bytes from 1.1.2.2: icmp_seq=0 ttl=254 time=2.137 ms 56 bytes from 1.1.2.2: icmp_seq=1 ttl=254 time=2.051 ms 56 bytes from 1.1.2.2: icmp_seq=2 ttl=254 time=1.996 ms 56 bytes from 1.1.2.2: icmp_seq=3 ttl=254 time=1.963 ms 56 bytes from 1.1.2.2: icmp_seq=4 ttl=254 time=1.991 ms --- Ping statistics for 1.1.2.
2. The intermediate device (Device B) adds the IP address of its outbound interface (1.1.2.1) to the RR option of the ICMP echo request, and forwards the packet. 3. Upon receiving the request, the destination device copies the RR option in the request and adds the IP address of its outbound interface (1.1.2.2) to the RR option. Then the destination device sends an ICMP echo reply. 4. The intermediate device adds the IP address of its outbound interface (1.1.1.
6. The source device thinks that the packet has reached the destination device after receiving the port-unreachable ICMP message, and the path to the destination device is 1.1.1.2 to 1.1.2.2 to 1.1.3.2. Prerequisites Before you use a tracert command, perform the tasks in this section. For an IPv4 network: • Enable sending of ICMP timeout packets on the intermediate devices (devices between the source and destination devices).
Test the network connectivity between Device A and Device C. If they cannot reach each other, locate the failed nodes in the network. Figure 3 Network diagram 1.1.1.1/24 1.1.1.2/24 Device A 1.1.2.1/24 1.1.2.2/24 Device B Device C Configuration procedure 1. Configure the IP addresses for devices as shown in Figure 3. 2. Configure a static route on Device A. system-view [DeviceA] ip route-static 0.0.0.0 0.0.0.0 1.1.1.2 [DeviceA] quit 3.
5. Use the debugging ip icmp command on Device A and Device C to verify that they can send and receive the specific ICMP packets, or use the display ip routing-table command to verify the connectivity between Device A and Device C. System debugging The device supports debugging for the majority of protocols and features and provides debugging information to help users diagnose errors.
To debug a feature module: Step Command Remarks 1. Enable debugging for a specified module in user view. debugging { all [ timeout time ] | module-name [ option ] } By default, all debugging functions are disabled. 2. (Optional.) Display the enabled debugging in any view.
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, HTTP, DHCP, or DNS operation uploads or downloads a file, gets a web page, gets an IP address through DHCP, or translates a domain name to an IP address. • An ICMP echo or UDP echo operation sends an ICMP echo request or a UDP packet. • An SNMP operation sends one SNMPv1 packet, one SNMPv2c packet, and one SNMPv3 packet.
Table 1 Performance metrics and NQA operation types Performance metric NQA operation types that can gather the metric Probe duration All NQA operation types excluding UDP jitter, path jitter, and voice Number of probe failures All NQA operation types excluding UDP jitter, path jitter, and voice Round-trip time UDP jitter and voice Number of discarded packets UDP jitter and voice One-way jitter (source-to-destination and destination-to-source) UDP jitter and voice One-way latency (source-to-desti
Step Enable the NQA server. 2. Command Remarks 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 ] [ vpn-instance vpn-instance-name ] • UDP listening service: nqa server udp-echo ip-address port-number [ tos tos ] [ vpn-instance vpn-instance-name ] 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. The ICMP echo operation is not supported in IPv6 networks. To test the reachability of an IPv6 address, use the ping ipv6 command.
The NQA client simulates the DHCP relay agent to forward DHCP requests for IP address acquisition from the DHCP server. The interface that performs the DHCP operation does not change its IP address. When the DHCP operation completes, the NQA client sends a packet to release the obtained IP address. To configure the DHCP operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view.
Step Specify the domain name that needs to be translated. 5. Command Remarks resolve-target domain-name By default, no domain name is specified. Configuring the FTP operation The FTP operation measures the time for the NQA client to transfer a file to or download a file from an FTP server. Follow these guidelines when you configure the FTP operation: • When you perform the put operation with the filename command configured, make sure the file exists on the NQA client.
Configuring the HTTP operation An HTTP operation measures the time for the NQA client to obtain data from an HTTP server. The TCP port number of the HTTP server must be 80. Otherwise, the HTTP operation fails. To configure an HTTP operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. nqa entry admin-name operation-tag By default, no NQA operation is created. 3. Specify the HTTP type and enter its view. type http N/A 4.
Jitter means inter-packet delay variance. A UDP jitter operation measures unidirectional and bidirectional jitters so that you can verify whether the network can carry jitter-sensitive services such as real-time voice and video services. The UDP jitter operation works as follows: 1. The NQA client sends UDP packets to the destination port at a regular interval. 2. The destination device takes a time stamp to each packet that it receives, and then sends the packet back to the NQA client. 3.
Step Command Remarks By default, no source IP address is specified. 12. (Optional.) Specify the source IP address for UDP 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 UDP packets can be sent out. NOTE: Use the display nqa result command or the display nqa statistics command to verify the UDP jitter operation. The display nqa history command does not display the UDP jitter operation results or statistics.
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 TCP type and enter its view. type tcp N/A 4. 5. Specify the destination address of TCP packets. Specify the destination port of TCP packets. By default, no destination IP address is specified.
Step Command Remarks By default, no destination port number is specified. 5. Specify the destination port of UDP packets. destination port port-number The destination port number must be the same as that of the listening service on the NQA server. 6. Specify the payload size in each UDP packet. data-size size The default setting is 100 bytes. 7. Specify the string to be filled in the payload of each UDP packet.
The voice operation requires both the NQA server and the NQA client. Before you perform a voice operation, configure a UDP listening service on the NQA server. For more information about UDP listening service configuration, see "Configuring the NQA server." The voice operation cannot repeat. To configure the voice operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view.
Step Command Remarks 12. Specify the number of voice packets to be sent in a voice probe. probe packet-number packet-number The default setting is 1000. 13. Specify the interval for sending voice packets. probe packet-interval packet-interval The default setting is 20 milliseconds. 14. 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 5000 milliseconds.
Enable sending ICMP destination unreachable packets on the destination device. If the destination device is an HP device, use the ip unreachables enable command. • For more information about the ip ttl-expires enable and the ip unreachable enable command, see Layer 3—IP Services Command Reference. To configure the path jitter operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view.
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. Specify an NQA operation type and enter its view. type { dhcp | dlsw | dns | ftp | http | icmp-echo | path-jitter | snmp | tcp | udp-echo | udp-jitter | voice } N/A (Optional.) Configure a description. description text By default, no description is configured. 3. 4. 5. (Optional.
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 an NQA operation type and enter its view. type { dhcp | dlsw | dns | ftp | http | icmp-echo | snmp | tcp | udp-echo } The collaboration function is not available for the path jitter, UDP jitter, and voice operations. 4. Configure a reaction entry.
The state of a reaction entry can be invalid, over-threshold, or below-threshold. • Before an NQA operation starts, the reaction entry is in invalid state. • If the threshold is violated, the state of the entry is set to over-threshold. Otherwise, the state of the entry is set to below-threshold. If the action to be triggered is configured as trap-only for a reaction entry, when the state of the entry changes, a trap message is generated and sent to the NMS.
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 operation to measure the reachability of a destination device. The ICMP template is supported in both IPv4 and IPv6 networks. To configure the ICMP template: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an ICMP template and enter its view. nqa template icmp name N/A 3. (Optional.) Specify the destination IPv4 or IPv6 address of the operation.
Step Command Remarks By default, the type is type A. 6. Configure the domain name resolution type. resolve-type { A | AAAA } 7. (Optional.) Configure the source port for probe packets. source port port-number 8. (Optional.) Specify the IPv4 or IPv6 address that is expected to be returned. A type A query resolves a domain name to a mapped IPv4 address, and a type AAAA query to a mapped IPv6 address. By default, no source port number is configured.
Step 6. Command (Optional.) Configure the expected data. Remarks By default, no expected data is configured. expect data expression [ offset number ] This command takes effect only when you configure the data-fill command. Configuring the HTTP template A feature that uses the HTTP template creates and starts the HTTP operation to measure the time the NQA client uses to obtain data from an HTTP server. In HTTP template view, you can configure the expected data.
Step Command Remarks (Optional.) Enter or paste the content of the GET request for the HTTP operation. N/A This step is required for the raw operation. (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. expect data expression [ offset number ] By default, no expected data is configured. 8. 9.
Step 8. Set the data transmission mode. Command Remarks mode { active | passive } The default mode is active. Configuring optional parameters for the NQA template To configure optional parameters for an NQA template: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA template and enter its view. nqa template { dns | ftp | http | icmp | tcp } name N/A 3. Configure a description. description text By default, no description is configured. 4.
Task Command Display history records of NQA operations. display nqa history [ admin-name operation-tag ] Display the current monitoring results of reaction entries. display nqa reaction counters [ admin-name operation-tag [ item-number ] ] Display the result of the NQA operation. display nqa result [ admin-name operation-tag ] Display NQA statistics. display nqa statistics [ admin-name operation-tag ] Display NQA server status.
[DeviceA-nqa-admin-test1-icmp-echo] destination ip 10.2.2.2 # Configure 10.1.1.2 as the next hop. The ICMP echo requests are sent through Device C to Device B. [DeviceA-nqa-admin-test1-icmp-echo] next-hop 10.1.1.2 # Configure the ICMP echo operation to perform 10 probes, specify the probe timeout time as 500 milliseconds, and configure the operation to repeat at an interval of 5000 milliseconds.
DHCP operation configuration example Network requirements As shown in Figure 8, configure and schedule a DHCP operation to test the time required for Router A to obtain an IP address from the DHCP server (Router B). Figure 8 Network diagram Configuration procedure # Create a DHCP operation to be performed to the destination IP address 10.1.1.2. system-view [RouterA] nqa entry admin test1 [RouterA-nqa-admin-test1] type dhcp [RouterA-nqa-admin-test1-dhcp] destination ip 10.1.1.
DNS operation configuration example Network requirements As shown in Figure 9, 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 9 Network diagram Configuration procedure # Assign each interface an IP address. (Details not shown.) # Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) # Create a DNS operation.
[DeviceA] display nqa history admin test 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 10, configure an FTP operation to test the time required for Device A to upload a file to the FTP server.
# Display the 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.
[DeviceA-nqa-admin-test1-http] operation get # Configure the operation to use HTTP version 1.0. (Version 1.0 is the default version, and this step can be omitted.) [DeviceA-nqa-admin-test1-http] version v1.0 # Enable the saving of history records. [DeviceA-nqa-admin-test1-http] history-record enable [DeviceA-nqa-admin-test1-http] quit # Start the HTTP operation. [DeviceA] nqa schedule admin test1 start-time now lifetime forever # After the HTTP operation runs for a period of time, stop the operation.
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 and configure a listening service to listen on the IP address 10.2.2.2 and UDP port 9000. system-view [DeviceB] nqa server enable [DeviceB] nqa server udp-echo 10.2.2.2 9000 4. Configure Device A: # Create a UDP jitter operation.
Positive SD square-sum: 754 Positive DS square-sum: 460 Min negative SD: 1 Min negative DS: 6 Max negative SD: 13 Max negative DS: 22 Negative SD number: 4 Negative DS number: 5 Negative SD sum: 38 Negative DS sum: 52 Negative SD average: 10 Negative DS average: 10 Negative SD square-sum: 460 Negative DS square-sum: 754 One way results: Max SD delay: 15 Max DS delay: 16 Min SD delay: 7 Min DS delay: 7 Number of SD delay: 10 Number of DS delay: 10 Sum of SD delay: 78 Sum of DS delay: 85
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 SD lost packets: 0 Square-Sum of DS delay: 49393 DS lost packets: 0 Lost packets for unknown reason: 0 SNMP operation configuration example Network requirements As shown in Figure 13, configure an SNMP operation to test the time the NQA client uses to get a value from the SNMP agent. Figure 13 Network diagram Configuration procedure 1. Assign each interface an IP address.
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.
# Enable the saving of history records. [DeviceA-nqa-admin-test1-tcp] history-record enable [DeviceA-nqa-admin-test1-tcp] quit # Start the TCP operation. [DeviceA] nqa schedule admin test1 start-time now lifetime forever # After the TCP operation runs for a period of time, stop the operation. [DeviceA] undo nqa schedule admin test1 # Display the results of the TCP operation.
# Enable the NQA server, and configure a listening service to listen on the IP address 10.2.2.2 and UDP port 8000. system-view [DeviceB] nqa server enable [DeviceB] nqa server udp-echo 10.2.2.2 8000 4. Configure Device A: # Create a UDP echo operation. system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type udp-echo # Configure 10.2.2.2 as the destination IP address and port 8000 as the destination port. [DeviceA-nqa-admin-test1-udp-echo] destination ip 10.2.2.
Figure 16 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, and configure a listening service to listen on IP address 10.2.2.2 and UDP port 9000. system-view [DeviceB] nqa server enable [DeviceB] nqa server udp-echo 10.2.2.2 9000 4.
Min positive SD: 1 Min positive DS: 1 Max positive SD: 204 Max positive DS: 1297 Positive SD number: 257 Positive DS number: 259 Positive SD sum: 759 Positive DS sum: 1797 Positive SD average: 2 Positive DS average: 6 Positive SD square-sum: 54127 Positive DS square-sum: 1691967 Min negative SD: 1 Min negative DS: 1 Max negative SD: 203 Max negative DS: 1297 Negative SD number: 255 Negative DS number: 259 Negative SD sum: 759 Negative DS sum: 1796 Negative SD average: 2 Negative DS aver
Max negative SD: 360 Max negative DS: 1297 Negative SD number: 1028 Negative DS number: 1022 Negative SD sum: 1028 Negative DS sum: 1022 Negative SD average: 4 Negative DS average: 5 Negative SD square-sum: 495901 Negative DS square-sum: 5419 One way results: Max SD delay: 359 Max DS delay: 985 Min SD delay: 0 Min DS delay: 0 Number of SD delay: 4 Number of DS delay: 4 Sum of SD delay: 1390 Sum of DS delay: 1079 Square-Sum of SD delay: 483202 SD lost packets: 0 Square-Sum of DS delay: 973
[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-path-jitter] quit # Start the path jitter operation. [DeviceA] nqa schedule admin test1 start-time now lifetime forever # After the path jitter operation runs for a period of time, stop the operation. [DeviceA] undo nqa schedule admin test1 # Display the results of the path jitter operation. [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Hop IP 10.1.1.
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 19, configure a static route to Router C with Router B as the next hop on Router A. Associate the static route, a track entry, and an NQA operation to monitor the state of the static route. Figure 19 Network diagram Configuration procedure 1. Assign each interface an IP address. (Details not shown.) 2.
# Create track entry 1, and associate it with reaction entry 1 of the ICMP echo operation (admin-test1). [RouterA] track 1 nqa entry admin test1 reaction 1 Verifying the configuration # On Router A, display information about all the track entries.
Reaction: 1 # Display brief information about active routes in the routing table on Router A. [RouterA] display ip routing-table Destinations : 12 Routes : 12 Destination/Mask Proto Cost NextHop Interface 0.0.0.0/32 Direct 0 Pre 0 127.0.0.1 InLoop0 10.2.1.0/24 Direct 0 0 10.2.1.2 Eth1/1 10.2.1.0/32 Direct 0 0 10.2.1.2 Eth1/1 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 Eth1/1 127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0 127.0.0.
Configuration procedure # Assign each interface an IP address. (Details not shown.) # Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) # Create ICMP template icmp 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.
[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 22, 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 22 Network diagram Configuration procedure 1.
Figure 23 Network diagram Configuration procedure # Assign each interface an IP address. (Details not shown.) # Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.) # 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.
# Specify the URL of the FTP server. [DeviceA-nqatplt-ftp-ftp] url ftp://admin:systemtest@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.
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.
The synchronization process is as follows: 1. Device A sends Device B an NTP message, which is timestamped when it leaves Device A. The time stamp is 10:00:00 am (T1). 2. When this NTP message arrives at Device B, Device B adds a timestamp showing the time when the message arrived at Device B. The timestamp is 11:00:01 am (T2). 3. When the NTP message leaves Device B, Device B adds a timestamp showing the time when the message left Device B. The timestamp is 11:00:02 am (T3). 4.
many NTP hops away a device is from the primary time server. A stratum 2 time server receives its time from a stratum 1 time server, and so on. To ensure time accuracy and availability, you can specify multiple NTP servers for a device. The device selects an optimal NTP server as the clock source based on parameters such as stratum. The clock that the device selects is called the reference source. For more information about clock selection, see the related protocols and standards.
Mode Working process Principle Application scenario A symmetric active peer and a symmetric passive peer can synchronize to each other. If both of them are synchronized, the peer with a higher stratum is synchronized to the peer with a lower stratum. As Figure 26 shows, this mode is most often used between two or more servers with the same stratum to operate as a backup for one another.
NTP security To improve time synchronization security, NTP provides the access control and authentication functions. NTP access control You can control NTP access by using an ACL. The access rights are in the following order, from least restrictive to most restrictive: • Peer—Allows time requests and NTP control queries (such as alarms, authentication status, and time server information) and allows the local device to synchronize itself to a peer device.
in the NTP message. If they are the same, the receiver accepts the message. Otherwise, it discards the message. NTP for MPLS VPNs The device supports multiple VPN instances when it functions as an NTP client or a symmetric active peer to realize time synchronization with the NTP server or symmetric passive peer in an MPLS VPN network. Only the client/server and symmetric active/passive modes support VPN instances. For more information about MPLS L3VPN, VPN instance, and PE, see MPLS Configuration Guide.
Configuration task list Tasks at a glance (Required.) Enabling the NTP service (Required.) Perform at least one of the following tasks: • Configuring NTP association modes • Configuring the local clock as a reference source (Optional.) Configuring access control rights (Optional.) Configuring NTP authentication (Optional.) Configuring NTP optional parameters Enabling the NTP service Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the NTP service.
Step Command Remarks • Specify an NTP server for the Specify an NTP server for the device. 2. device: ntp-service unicast-server { ip-address | server-name } [ vpn-instance vpn-instance-name ] [ authentication-keyid keyid | priority | source interface-type interface-number | version number ] * • Specify an IPv6 NTP server for By default, no NTP server is specified for the device.
Step Command Remarks • Specify a symmetric-passive 2. Specify a symmetric-passive peer for the device. peer: ntp-service unicast-peer { ip-address | peer-name } [ vpn-instance vpn-instance-name ] [ authentication-keyid keyid | priority | source interface-type interface-number | version number ] * • Specify an IPv6 By default, no symmetric-passive peer is specified.
Step 3. Command Configure the device to operate in NTP broadcast server mode. ntp-service broadcast-server [ authentication-keyid keyid | version number ] * Remarks By default, the device does not operate in broadcast server mode. After you execute the command, the device receives NTP broadcast messages from the specified interface.
Step Command Remarks • Configure the device to operate 3. Configure the device to operate in multicast server mode. in multicast server mode: ntp-service multicast-server [ ip-address ] [ authentication-keyid keyid | ttl ttl-number | version number ] * • Configure the device to operate in multicast server mode: ntp-service ipv6 multicast-server ipv6-multicast-address [ authentication-keyid keyid | ttl ttl-number ] * By default, the device does not operate in multicast server mode.
NTP server on the client. The key IDs and key values configured on the server and client must be the same. Otherwise, NTP authentication fails. To configure NTP authentication for a client: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable NTP authentication. ntp-service authentication enable By default, NTP authentication is disabled. 3. Configure an NTP authentication key.
Table 3 NTP authentication results Client Enable NTP authenticati on Yes Yes Yes Yes Yes No Server Configure a key and configure it as a trusted key Yes Yes Yes No N/A N/A Associate the key with an NTP server Yes Enable NTP authenticati on Yes Yes Yes Yes No Yes N/A No N/A N/A N/A Configure a key and configure it as a trusted key Authentication result Yes Succeeded. NTP messages can be sent and received correctly. No Failed. NTP messages cannot be sent and received correctly.
Step Command Remarks 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. • Associate the specified key with 5. Associate the specified key with a passive peer.
Active peer Passive peer Enable NTP authentic ation Configure a key and configure it as a trusted key Associate the key with an passive peer Enable NTP authentication Configure a key and configure it as a trusted key Yes Yes Yes Yes No Failed. NTP messages cannot be sent and received correctly. Yes Yes Yes No N/A Failed. NTP messages cannot be sent and received correctly. Yes N/A No Yes N/A Failed. NTP messages cannot be sent and received correctly.
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 Broadcast client Enable NTP authentic ation Configure a key and configure it as a trusted key Associate the key with a broadcast server Enable NTP authenticati on Configure a key and configure it as a trusted key Yes No Yes No N/A No authentication. NTP messages can be sent and received correctly. Yes N/A No Yes N/A Failed. NTP messages cannot be sent and received correctly. Yes N/A No No N/A No authentication. NTP messages can be sent and received correctly.
Step Command Remarks 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. interface interface-type interface-number N/A • Associate the specified key with 6.
Multicast server Enable NTP authentic ation Yes Yes Yes No No Configure a key and configure it as a trusted key No N/A N/A N/A N/A Multicast client Associate the key with a multicast server Yes Enable NTP authenticatio n No No Yes No No N/A Yes N/A No Configure a key and configure it as a trusted key Authentication result N/A No authentication. NTP messages can be sent and received correctly. N/A Failed. NTP messages cannot be sent and received correctly. N/A No authentication.
To specify the source interface for NTP messages: Step Enter system view. 1. Command Remarks system-view N/A • Specify the source interface for Specify the source interface for NTP messages. 2. NTP messages: ntp-service source-interface interface-type interface-number • Specify the source interface for By default, no source interface is specified for NTP messages.
A single device can have a maximum of 128 concurrent associations, including static associations and dynamic associations. Perform this task to restrict the number of dynamic associations to prevent dynamic associations from occupying too many system resources. To configure the maximum number of dynamic associations: Step Command Remarks 1. Enter system view. system-view N/A 2. Configure the maximum number of dynamic sessions allowed to be established.
Displaying and maintaining NTP Execute display commands in any view. Task Command Display information about NTP service status. display ntp-service status Display information about IPv4 NTP associations. display ntp-service sessions [ verbose ] Display information about IPv6 NTP associations. display ntp-service ipv6 sessions [ verbose ] Display brief information about the NTP servers from the local device back to the primary reference source.
Local mode: client Reference clock ID: 1.0.1.11 Leap indicator: 00 Clock jitter: 0.000977 s Stability: 0.000 pps Clock precision: 2^-10 Root delay: 0.00383 ms Root dispersion: 16.26572 ms Reference time: d0c6033f.b9923965 Wed, Dec 29 2010 18:58:07.724 The output shows that Device B has been synchronized to Device A, the clock stratum level of Device B is 3, and the clock stratum level of Device A is 2. # Display IPv4 NTP association information for Device B.
system-view [DeviceB] ntp-service enable # Specify Device A as the IPv6 NTP server of Device B so that Device B is synchronized to Device A. [DeviceB] ntp-service ipv6 unicast-server 3000::34 4. Verify the configuration: # Display the NTP status of Device B after clock synchronization. [DeviceB] display ntp-service status Clock status: synchronized Clock stratum: 3 System peer: 3000::34 Local mode: client Reference clock ID: 163.29.247.19 Leap indicator: 00 Clock jitter: 0.
• Configure Device C to operate in symmetric-active mode and specify Device B as the passive peer of Device C. Figure 31 Network diagram Configuration procedure 1. Set the IP address for each interface as shown in Figure 31. (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 3. [DeviceA] ntp-service refclock-master 3 3.
Clock status: synchronized Clock stratum: 3 System peer: 3.0.1.33 Local mode: sym_passive Reference clock ID: 3.0.1.33 Leap indicator: 00 Clock jitter: 0.000916 s Stability: 0.000 pps Clock precision: 2^-17 Root delay: 0.00609 ms Root dispersion: 1.95859 ms Reference time: 83aec681.deb6d3e5 Sun, Jan 4 1970 5:56:17.869 # Display IPv4 NTP association information for Device B.
Figure 32 Network diagram Device A NTP server 3000::34/64 3000::35/64 Device B NTP client/ symmetric passive peer 3000::36/64 Device C Symmetric active peer Configuration procedure 1. Set the IP address for each interface as shown in Figure 32. (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 3. [DeviceA] ntp-service refclock-master 3 3.
Clock stratum: 3 System peer: 3000::36 Local mode: sym_passive Reference clock ID: 163.29.247.19 Leap indicator: 11 Clock jitter: 0.000977 s Stability: 0.000 pps Clock precision: 2^-10 Root delay: 0.01855 ms Root dispersion: 9.23483 ms Reference time: d0c6047c.97199f9f Wed, Dec 29 2010 19:03:24.590 # Display IPv6 NTP association information for Device B. [DeviceB] display ntp-service ipv6 sessions Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured.
Figure 33 Network diagram Eth1/1 3.0.1.31/24 Router C NTP broadcast server Eth1/1 3.0.1.30/24 Router A NTP broadcast client Eth1/1 3.0.1.32/24 Router B NTP broadcast client Configuration procedure 1. Set the IP address for each interface as shown in Figure 33. (Details not shown.) 2. Configure Router C: # Enable the NTP service. system-view [RouterC] ntp-service enable # Specify the local clock as the reference source, with the stratum level 2.
# Router A and Router B get synchronized upon receiving a broadcast message from Router C. Display the NTP status of Router A after clock synchronization. [RouterA-Ethernet1/1] 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.044281 s Stability: 0.000 pps Clock precision: 2^-10 Root delay: 0.00229 ms Root dispersion: 4.12572 ms Reference time: d0d289fe.
Figure 34 Network diagram Configuration procedure 1. Set the IP address for each interface as shown in Figure 34. (Details not shown.) 2. Configure Router C: # Enable the NTP service. system-view [RouterC] ntp-service enable # Specify the local clock as the reference source, with the stratum level 2. [RouterC] ntp-service refclock-master 2 # Configure Router C to operate in multicast server mode and send multicast messages through Ethernet 1/1.
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 Router D has been synchronized to Router C, the clock stratum level of Router D is 3, and the clock stratum level of Router C is 2. # Display IPv4 NTP association information for Router D.
Leap indicator: 00 Clock jitter: 0.165741 s Stability: 0.000 pps Clock precision: 2^-10 Root delay: 0.00534 ms Root dispersion: 4.51282 ms Reference time: d0c61289.10b1193f Wed, Dec 29 2010 20:03:21.065 The output shows that Router A has been synchronized to Router C, the clock stratum level of Router A is 3, and the clock stratum level of Router C is 2.
2. Configure Router C: # Enable the NTP service. system-view [RouterC] ntp-service enable # Specify the local clock as the reference source, with the stratum level 2. [RouterC] ntp-service refclock-master 2 # Configure Router C to operate in IPv6 multicast server mode and send multicast messages through Ethernet 1/1. [RouterC] interface ethernet 1/1 [RouterC-Ethernet1/1] ntp-service ipv6 multicast-server ff24::1 3. Configure Router D: # Enable the NTP service.
Total sessions : 1 The output shows that an association has been set up between Router D and Router C. 5. Configure Router B: Because Router A and Router C are on different subnets, you must enable the multicast functions on Router B before Router A can receive IPv6 multicast messages from Router C. # Enable the IPv6 multicast function.
Reference: 127.127.1.0 Clock stratum: 2 Reachabilities: 2 Poll interval: 64 Last receive time: 71 Offset: -0.0 Roundtrip delay: 0.0 Dispersion: 0.0 Total sessions : 1 The output shows that an association has been set up between Router A and Router C. Configuration example for NTP client/server mode with authentication Network requirements • As shown in Figure 36, configure the local clock of Device A as a reference source, with the stratum level 2.
# Specify Device A as the NTP server of Device B, and associate the server with key 42. [DeviceB] ntp-service unicast-server 1.0.1.11 authentication-keyid 42 Before Device B can synchronize its clock to that of Device A, enable NTP authentication for Device A. 4. Configure NTP authentication on Device A: # Enable NTP authentication. [DeviceA] ntp-service authentication enable # Set an authentication key, and input the key in plain text.
Configuration example for NTP broadcast mode with authentication Network requirements As shown in Figure 37, Router C functions as the NTP server for multiple devices on different network segments and synchronizes the time among multiple devices. Router A and Router B authenticate the reference source. • Configure Router C's local clock as a reference source, with the stratum level 3. • Configure Router C to operate in broadcast server mode and send out broadcast messages from Ethernet 1/1.
3. Configure Router B: # Enable the NTP service. system-view [RouterB] ntp-service enable # Enable NTP authentication on Router B. 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.
Clock stratum: 4 System peer: 3.0.1.31 Local mode: bclient Reference clock ID: 3.0.1.31 Leap indicator: 00 Clock jitter: 0.006683 s Stability: 0.000 pps Clock precision: 2^-10 Root delay: 0.00127 ms Root dispersion: 2.89877 ms Reference time: d0d287a7.3119666f Sat, Jan 8 2011 6:50:15.191 The output shows that Router B has been synchronized to Router C, the clock stratum level of Router B is 4, and the clock stratum level of Router C is 3. # Display IPv4 NTP association information for Router B.
Figure 38 Network diagram VPN 1 VPN 1 CE 1 CE 3 S2/0 S2/0 PE 1 S2/0 P S2/1 S2/0 PE 2 S2/1 S2/1 S2/2 S2/0 S2/2 MPLS backbone S2/0 S2/0 CE 2 CE 4 VPN 2 VPN 2 Device Interface IP address Device Interface IP address CE 1 S2/0 10.1.1.1/24 PE 1 S2/0 10.1.1.2/24 CE 2 S2/0 10.2.1.1/24 S2/1 172.1.1.1/24 CE 3 S2/0 10.3.1.1/24 S2/2 10.2.1.2/24 CE 4 S2/0 10.4.1.1/24 S2/0 10.3.1.2/24 S2/0 172.1.1.2/24 S2/1 172.2.1.2/24 S2/1 172.2.1.1/24 S2/2 10.4.1.
Clock status: synchronized Clock stratum: 3 System peer: 10.1.1.1 Local mode: client Reference clock ID: 10.1.1.1 Leap indicator: 00 Clock jitter: 0.005096 s Stability: 0.000 pps Clock precision: 2^-10 Root delay: 0.00655 ms Root dispersion: 1.15869 ms Reference time: d0c62687.ab1bba7d Wed, Dec 29 2010 21:28:39.668 [PE2] display ntp-service sessions source reference stra reach poll now offset delay disper ******************************************************************************** [1245]10.1.1.
Figure 39 Network diagram VPN 1 VPN 1 CE 1 Symmetric passive peer CE 3 S2/0 S2/0 S2/0 PE 1 Symmetric active peer S2/1 P PE 2 S2/1 S2/1 S2/0 S2/2 S2/0 S2/2 MPLS backbone S2/0 S2/0 CE 2 CE 4 VPN 2 VPN 2 Device Interface IP address Device Interface IP address CE 1 S2/0 10.1.1.1/24 PE 1 S2/0 10.1.1.2/24 CE 2 S2/0 10.2.1.1/24 S2/1 172.1.1.1/24 CE 3 S2/0 10.3.1.1/24 S2/2 10.2.1.2/24 CE 4 S2/0 10.4.1.1/24 S2/0 10.3.1.2/24 S2/0 172.1.1.2/24 S2/1 172.2.1.
Reference clock ID: 10.1.1.1 Leap indicator: 00 Clock jitter: 0.005096 s Stability: 0.000 pps Clock precision: 2^-10 Root delay: 0.00655 ms Root dispersion: 1.15869 ms Reference time: d0c62687.ab1bba7d Wed, Dec 29 2010 21:28:39.668 [PE1] display ntp-service sessions source reference stra reach poll now offset delay disper ******************************************************************************** [1245]10.1.1.1 127.127.1.0 2 1 64 519 -0.0 0.
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 Remarks • For IPv4: Specify an NTP server for the device. 2. sntp unicast-server { ip-address | server-name } [ vpn-instance vpn-instance-name ] [ authentication-keyid keyid | source interface-type interface-number | version number ] * • For IPv6: sntp ipv6 unicast-server { ipv6-address | server-name } [ vpn-instance vpn-instance-name ] [ authentication-keyid keyid | source interface-type interface-number ] * By default, no NTP server is specified for the device.
Step Command Remarks • For IPv4: Associate the SNTP authentication key with the specific NTP server. 5. sntp unicast-server { ip-address | server-name } [ vpn-instance vpn-instance-name ] authentication-keyid keyid • For IPv6: sntp ipv6 unicast-server { ipv6-address | server-name } [ vpn-instance vpn-instance-name ] authentication-keyid keyid By default, no NTP server is specified. Displaying and maintaining SNTP Execute display commands in any view.
# Configure an NTP authentication key, with the key ID of 10 and key value of aNiceKey. Input the key in plain text. [DeviceA] ntp-service authentication-keyid 10 authentication-mode md5 simple aNiceKey # Specify the key as a trusted key. [DeviceA] ntp-service reliable authentication-keyid 10 3. Configure Device B: # Enable the SNTP service. system-view [DeviceB] sntp enable # Enable SNTP authentication on Device B.
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 42 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 | acl ipv6 ipv6-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 | acl ipv6 ipv6-acl-number ] * Use either method.
Security model Security model keyword for the group No authentication, no privacy Neither authentication nor privacy Security key settings for the user Remarks None The authentication and privacy keys, if configured, do not take effect. To configure SNMPv3 basic parameters: Step 1. Enter system view. Command Remarks system-view N/A By default, the SNMP agent is disabled.
Step 8. 9. Command (Optional.) Create or update a MIB view. snmp-agent mib-view { excluded | included } view-name oid-tree [ mask mask-value ] Create an SNMPv3 group. snmp-agent group v3 group-name [ authentication | privacy ] [ read-view view-name ] [ write-view view-name ] [ notify-view view-name ] [ acl acl-number | acl ipv6 ipv6-acl-number ] * 10. (Optional.) Convert a plaintext key to an encrypted key.
The SNMP agent logs Get requests, Set requests, Set responses, and SNMP notifications, but does not log Get responses. • Get operation—The agent logs the IP address of the NMS, name of the accessed node, and node OID. • Set operation—The agent logs the NMS' IP address, name of accessed node, node OID, variable value, and error code and index for the Set operation. • Notification tracking—The agent logs the SNMP notifications after sending them to the NMS.
Step Command Remarks 2. Enable notifications globally. snmp-agent trap enable [ protocol | standard [ authentication | coldstart | linkdown | linkup | warmstart ] * | system ] By default, whether SNMP notifications are enabled varies with modules. 3. Enter interface view. interface interface-type interface-number N/A 4. Enable link state notifications. enable snmp trap updown By default, link state notifications are enabled.
Step Command Remarks • (Method 1) Send traps to the target 2. Configure a target host.
Displaying the SNMP settings Execute display commands in any view. Task Command Display SNMP agent system information, including the contact, physical location, and SNMP version. display snmp-agent sys-info [ contact | location | version ] Display SNMP agent statistics. display snmp-agent statistics Display the local engine ID. display snmp-agent local-engineid Display SNMP group information. display snmp-agent group [ group-name ] Display remote engine IDs.
# 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. system-view [Agent] snmp-agent sys-info version v1 [Agent] snmp-agent community read public [Agent] snmp-agent community write private # Configure contact and physical location information for the agent. [Agent] snmp-agent sys-info contact Mr.
SNMPv3 configuration example Network requirements As shown in Figure 44, the NMS (1.1.1.2/24) uses SNMPv3 to monitor and manage the interface status of the agent (1.1.1.1/24). The agent automatically sends notifications to report events to the NMS. The default UDP port 162 is used for SNMP notifications. The NMS and the agent perform authentication when they set up an SNMP session. The authentication algorithm is SHA-1 and the authentication key is 123456TESTauth&!.
{ Set the authentication key to 123456TESTauth&! and the privacy key to 123456TESTencr&!. { Set the timeout time and maximum number of retries. For information about configuring the NMS, see the NMS manual. NOTE: The SNMP settings on the agent and the NMS must match. 3. Verify the configuration: # Try to get the MTU value of NULL0 interface from the agent. The get attempt succeeds. Send request to 1.1.1.1/161 ... Protocol version: SNMPv3 Operation: Get Request binding: 1: 1.3.6.1.2.1.2.2.1.4.
Configuring RMON Overview Remote Network Monitoring (RMON) is an enhancement to SNMP. It enables proactive remote monitoring and management of network devices and subnets. An RMON monitor periodically or continuously collects traffic statistics for the network attached to a port on the managed device. The managed device can automatically send a notification when a statistic crosses an alarm threshold, so the NMS does not need to constantly poll MIB variables and compare the results.
• None—Takes no actions. Alarm group The RMON alarm group monitors alarm variables, such as the count of incoming packets (etherStatsPkts) on an interface. After you create an alarm entry, the RMON agent samples the value of the monitored alarm variable regularly. If the value of the monitored variable is greater than or equal to the rising threshold, a rising alarm event is triggered.
Sample types for the alarm group and the private alarm group The RMON agent supports the following sample types: • absolute—RMON compares the value of the monitored variable with the rising and falling thresholds at the end of the sampling interval. • delta—RMON subtracts the value of the monitored variable at the previous sample from the current value, and then compares the difference with the rising and falling thresholds.
To create an RMON history control entry: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter Ethernet interface view. interface interface-type interface-number N/A 3. Create an entry for the interface in the RMON history control table. rmon history entry-number buckets number interval sampling-interval [ owner text ] By default, the RMON history control table does not contain entries. You can create up to 100 history control entries.
Step 2. (Optional.) Create an event entry in the event table. Command Remarks rmon event entry-number [ description string ] { log | log-trap security-string | none | trap security-string } [ owner text ] By default, the RMON event table does not contain entries. • Create an entry in the alarm table: 3. Create an entry in the alarm table or private alarm table.
Figure 46 Network diagram Configuration procedure # Create an RMON Ethernet statistics entry for Ethernet 1/1. system-view [Sysname] interface ethernet 1/1 [Sysname-Ethernet1/1] rmon statistics 1 owner user1 # Display statistics collected by the RMON agent for Ethernet 1/1. display rmon statistics ethernet 1/1 EtherStatsEntry 1 owned by user1 is VALID. Interface : Ethernet1/1
Configuration procedure # Create an RMON history control entry to sample traffic statistics every one minute for Ethernet 1/1. Retain up to eight samples for the interface in the history statistics table. system-view [Sysname] interface ethernet 1/1 [Sysname-Ethernet1/1] rmon history 1 buckets 8 interval 60 owner user1 # Display the history statistics collected for Ethernet 1/1.
dropevents : 0 , octets : 898 packets : 9 , broadcast packets : 2 multicast packets : 6 , CRC alignment errors : 0 undersize packets : 0 , oversize packets : 0 fragments : 0 , jabbers : 0 collisions : 0 , utilization : 0 dropevents : 0 , octets : 766 packets : 7 , broadcast packets : 0 Sampling record 7 : multicast packets : 6 , CRC alignment errors : 0 undersize packets : 0 , oversize packets : 0 fragments : 0 , jabbers : 0 collisions : 0 , utilization : 0 dropeve
[Sysname] snmp-agent target-host trap address udp-domain 1.1.1.2 params securityname public # Create an RMON Ethernet statistics entry for Ethernet 1/1. [Sysname] interface ethernet 1/1 [Sysname-Ethernet1/1] rmon statistics 1 owner user1 [Sysname-Ethernet1/1] quit # Create an RMON event entry and an RMON alarm entry to send SNMP traps when the delta sample for 1.3.6.1.2.1.16.1.1.1.4.1 exceeds 100 or drops below 50. [Sysname] rmon event 1 trap public owner user1 [Sysname] rmon alarm 1 1.3.6.1.2.1.16.1.1.1.
Configuring NETCONF Overview Network Configuration Protocol (NETCONF) is an XML-based network management protocol. It provides programmable mechanisms to manage and configure network devices. Through NETCONF, you can configure device parameters, retrieve parameter values, and get statistics information. NETCONF messages are XML-based with good filtering capabilities.
NETCONF message format NETCONF All NETCONF messages are XML-based and comply with RFC 4741. The NETCONF operations supported by the device and the operable data must comply with the XSD standards, which are defined in the XSD document provided by HP. Any incoming NETCONF messages must pass XSD check before it can be processed. If a NETCONF message fails XSD check, the device sends an error message to the client.
How to use NETCONF You can use NETCONF to manage and configure devices by using the methods in Table 10.
NETCONF configuration task list Task at a glance (Optional.) Enabling NETCONF over SOAP (Required.) Establishing a NETCONF session (Optional.) Subscribing to event notifications (Optional.) Locking/unlocking the configuration (Optional.) Performing the get/get-bulk operation (Optional.) Performing the get-config/get-bulk-config operation (Optional.) Performing the edit-config operation (Optional.) Saving, rolling back, and loading the configuration (Optional.) Filtering data (Optional.
Entering xml view Task Command Remarks Enter XML view. xml Available in user view. Exchanging capabilities After you enter XML view, the client and the device exchange their capabilities before you can perform subsequent operations. The device automatically advertises its NETCONF capabilities to the client in a hello message as follows: urn:ietf:pa rams:netconf:base:1.
Subscription procedure # Copy the following message to the client to complete the subscription: NETCONF PAGE 144 For more information about error messages, see RFC 4741. Example for subscribing to event notifications Network requirements Configure a client to subscribe to all events with no time limitation. After the subscription is successful, all events on the device are sent to the client before the session between the device and client is terminated. Configuration procedure # Enter XML view. xml # Exchange capabilities. PAGE 145 # When another client (192.168.100.130) logs in to the device, the device sends the following text to notify the client that has subscribed to all events: 2011-01-04T12:30:52 SHELL SHELL_LOGIN 6 Notification VTY logged in from 192.168.100.
Unlocking the configuration # Copy the following text to the client to unlock the configuration: After receiving the unlock request, the device returns a response in the following format if the unlock operation is successful: PAGE 147Verifying 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: PAGE 148 Specify the module, submodule, table name, and column name Where, the parameter can be or . The element is used to filter data, and it can contain module name, submodule name, table name, and column name. • If the module name and the submodule name are not provided, the operation retrieves the data for all modules and submodules.
Device state and configuration data within the specified range Performing the get-config/get-bulk-config operation The get-config and get-bulk-config operations are used to retrieve all non-default configurations, which are configured by means of CLI, MIB, and Web. The and messages can contain the element for filtering data.
Default operation when an error occurs Specify the module name, submodule name, table name, and column name After receiving the edit-config request, the device returns a response in the following format if the operation is successful: PAGE 151Verifying the configuration If the client receives the following text, the get-config operation is successful: PAGE 152 98
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.0 # Retrieve configuration data for the Syslog module.
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.0 # Retrieve a data entry for the interface table.
1 Aux0 Aux0 1 5 1 Aux0 Interface 1 2 ]]>]]> Example for changing the value of a parameter Network requirements Change the log buffer size for the Syslog module to 512. Configuration procedure # Enter XML view.
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. Saving the configuration # Copy the following text to the client to save the device configuration to a specified file:
Loading the configuration After you perform the load operation, the loaded configurations are merged into the current configuration: New configurations are directly loaded, and the configurations that already exist in the current configuration are replaced by those loaded from the configuration file. # Copy the following text to the client to load a configuration file for the device: PAGE 157 Verifying the configuration If the client receives the following response, the save operation is successful: # Examine the storage media of the device to verify that the files my_config.cfg and my_config.mdb exist.
Conditional match To implement a complex data filtering with digits and character strings, you can add a match attribute for a specific element. Table 11 lists the conditional match operators.
Example for filtering data with regular expression match Network requirements Retrieve all data including colons in the Description column of the Interfaces table under the Ifmgr module. Configuration procedure # Enter XML view. xml # Exchange capabilities.
Verifying the configuration If the client receives the following text, the operation is successful. PAGE 1612688 Ten-GigabitEthernet6/0/2:4 Interface 2689 Ten-GigabitEthernet6/0/3:1 Interface 2690 Ten-GigabitEthernet6/0/3:2 Interface 2691 Ten-GigabitEthernet6/0/3:3 Interface 2692 Ten-GigabitEthernet6/0/
# Retrieve data in the Name column with the ifIndex value not less than 5000 in the Interfaces table under the Ifmgr module. PAGE 163Configuration procedure # Copy the following text to the client to execute the commands: Commands The element can contain multiple commands, with one command on one line. After receiving the CLI operation request, the device returns a response in the following format if the CLI operation is successful:
Verifying the configuration If the client receives the following text, the operation is successful. display current-configuration # version 5.3.1, # sysname ab # ftp server enable ftp update fast ftp timeout 2000 # domain default enable system # telnet server enable # vlan 1 # vlan 1000 # radius scheme system primary authentication 127.0.0.
Configuration session ID line information Name of the use creating the session Time when the session was created Whether the session holds a lock For example, to get NETCONF session information: # Enter XML view. xml # Copy the following message to the client to exchange capabilities with the device. PAGE 166# Copy the following message to the client to terminate the specified NETCONF session: Specified session-ID After receiving the kill-session request, the device returns a response in the following format if the kill-session operation is successful: PAGE 167Returning to the CLI To return from XML view to the CLI, send the following close-session request: When the device receives the close-session request, it sends the following response and returns to CLI's user view: PAGE 168Appendix Appendix A Supported NETCONF operations Table 12 lists the NETCONF operations available with Comware V7. Table 12 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 169Operation 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 170Operation 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 171Operation 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 merget 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 the 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 175Operation 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 177Operation 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 xmlns="urn:ietf:params:xml:ns:netconf:ba se:1.
Configuring port mirroring Overview Port mirroring refers to the process of copying the packets passing through a port to the monitor port connecting to a monitoring device for packet analysis. Terminology The following terms are used in port mirroring configuration. Mirroring source The mirroring source can be one or more monitored ports, which are called "source ports." Packets passing through them are copied to a port connecting to a monitoring device for packet analysis.
Figure 49 Local port mirroring implementation As shown in Figure 49, the source port Ethernet 1/1 and monitor port Ethernet 1/2 reside on the same device. Packets received on Ethernet 1/1 are copied to Ethernet 1/2, which then forwards the packets to the data monitoring device for analysis. Configuring local port mirroring Local port mirroring takes effect only when the source ports and the monitor port are configured. Local port mirroring configuration task list Tasks at a glance (Required.
Configuration restrictions and guidelines When you configure source ports for a local mirroring group, follow these restrictions and guidelines: • A mirroring group can contain multiple source ports. • A port can belong to only one mirroring group. Configuration procedure To configure source ports in system view: Step Command Remarks 1. Enter system view. system-view N/A 2. Configure source ports for the specified local mirroring group.
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.
Figure 50 Network diagram Configuration procedure # Create local mirroring group 1. system-view [Device] mirroring-group 1 local # Configure Ethernet 1/1 and Ethernet 1/2 as source ports and port Ethernet 1/3 as the monitor port for local mirroring group 1. [Device] mirroring-group 1 mirroring-port ethernet 1/1 ethernet 1/2 both [Device] mirroring-group 1 monitor-port ethernet 1/3 # Disable the spanning tree feature on the monitor port Ethernet 1/3.
Configuring samplers A sampler samples packets. The sampler selects a packet from among sequential packets, and it sends the packet to other service modules for processing. The following sampling modes are available: • Fixed mode—The first packet is selected from among sequential packets in each sampling. • Random mode—Any packet might be selected from among sequential packets in each sampling. A sampler can be used to sample packets for NetStream.
• Configure fixed sampling in the inbound direction to select the first packet from among 100 packets. • Configure random sampling in the outbound direction to select one packet randomly from among 200 packets. Figure 51 Network diagram Configuration procedure # Create sampler 100 in fixed sampling mode, and set the rate to 100. The first packet of 100 packets is selected.
Configuring NetStream Overview Conventional ways to collect traffic statistics, like SNMP and port mirroring, cannot provide precise network management because of inflexible statistical methods or the high cost of required dedicated servers. This calls for a new technology to collect traffic statistics. NetStream provides the statistics of network traffic flows, and it can be deployed on access, distribution, and core layers.
• NetStream collector—The NSC is usually a program running in an operation system. It parses the packets received from the NDE, and then it stores the statistics to the database for the NDA. The NSC can gather data from multiple NDEs. • NetStream data analyzer—The NDA analyzes network traffic. It collects statistics from the NSC, performs further process for the statistics, and generates various reports for traffic billing, network planning, and attack detection and monitoring.
NetStream aggregation data export NetStream aggregation merges the flow statistics according to the aggregation criteria of an aggregation mode, and it sends the summarized data to the NetStream server. The NetStream aggregation data export uses less bandwidth than the traditional data export. Table 13 lists the available aggregation modes. In each mode, the system merges flows into one aggregate flow if each aggregation criterion is of the same value, and records the statistics of the aggregate flow.
Aggregation mode Aggregation criteria Source prefix Prefix-port aggregation • • • • • • • • • • • • • • • ToS • • • • • ToS • • • • • ToS • • • • • • • • • ToS • • • • • • ToS ToS-AS aggregation ToS-source-prefix aggregation ToS-destination-prefix aggregation ToS- prefix aggregation ToS-protocol-port aggregation ToS-BGP-nexthop Destination prefix Source address mask length Destination address mask length ToS Protocol number Source port Destination port Inbound interface index Outbound int
In an aggregation mode with AS, if the packets are not forwarded according to the BGP routing table, the AS number cannot be obtained. In the aggregation mode of ToS-BGP-nexthop, if the packets are not forwarded according to the BGP routing table, the BGP next hop cannot be obtained.
Figure 53 NetStream configuration flow Complete these tasks to configure NetStream: Tasks at a glance Remarks (Required.) Enabling NetStream on an interface N/A (Optional.) Configuring NetStream filtering N/A (Optional.) Configuring NetStream sampling N/A (Optional.) Configuring attributes of the NetStream data export N/A (Optional.) Configuring NetStream flow aging N/A (Required.
Step Command Remarks 2. Enter interface view. interface interface-type interface-number N/A 3. Enable NetStream on the interface. ip netstream { inbound | outbound } By default, NetStream is disabled on an interface. Configuring NetStream filtering When you configure NetStream filtering, follow these guidelines: • When NetStream filtering and sampling are both configured, packets are filtered first, and then the matching packets are sampled.
• Statistics about source AS, destination AS, and peer ASs in version 5 or version 9 format. • Statistics about BGP next hop in version 9 format only. To configure the NetStream export format: Step 1. Enter system view. 2. Configure the NetStream data export format, and specify whether to record AS and BGP next hop information.
Configuring the refresh rate for NetStream version 9 templates Version 9 is template-based and supports formats that can be defined, so the NetStream-enabled device needs to resend a new template to the NetStream server for an update. If the version 9 format is changed on the NetStream-enabled device and is not updated on the NetStream server, the server cannot associate the received statistics with its proper fields.
Periodical aging Periodical aging uses the following methods: • Inactive flow aging—A flow is considered inactive if no packet for this NetStream entry arrives in the time specified by the ip netstream timeout inactive command. The inactive flow entry remains in the cache until the inactive timer expires. Then the inactive flow entry is aged out and its statistics, which can no longer be displayed by the display ip netstream cache command, are sent to the NetStream server.
Step 3. Command Configure forced aging of the NetStream entries. Remarks 4. Set the maximum entries that the cache can accommodate: ip netstream max-entry max-entries 5. Exit to user view: quit Use either method. By default, the cache can accommodate up to 10000 entries. Age out and export NetStream data, and clear the cache: reset ip netstream statistics Configuring the NetStream data export Configuring the NetStream traditional data export Step Command Remarks 1. Enter system view.
Step 1. 2. 3. Command Remarks Enter system view. system-view N/A Set a NetStream aggregation mode and enter its view. ip netstream aggregation { as | destination-prefix | prefix | prefix-port | protocol-port | source-prefix | tos-as | tos-bgp-nexthop | tos-destination-prefix | tos-prefix | tos-protocol-port | tos-source-prefix } N/A Configure the destination address and destination UDP port number for the NetStream aggregation data export.
Task Command Age out and export all NetStream data, and clear the cache. reset ip netstream statistics NetStream traditional data export configuration example Network requirements As shown in Figure 55, configure NetStream on Router A to collect statistics on packets passing through it. Enable NetStream for incoming traffic on Ethernet 1/1 and for outgoing traffic on Ethernet 1/2. Configure the router to export NetStream traditional data to UDP port 5000 of the NetStream server at 12.110.2.2/16.
Flow active timeout (minutes) : 30 Flow inactive timeout (seconds) : 30 Max number of entries : 1024 IP active flow entries : 2 MPLS active flow entries : 0 L2 active flow entries : 0 IPL2 active flow entries : 0 IP flow entries been counted : 0 MPLS flow entries been counted : 0 L2 flow entries been counted : 0 IPL2 flow entries been counted : 0 Last statistics reset time : Never IP packet size distribution (11 packets in total): 1-32 64 96 128 160 192 224 256 288 320 352
NetStream aggregation data export configuration example Network requirements As shown in Figure 56, configure NetStream on Router A to meet the following requirements: • Router A exports NetStream traditional data in the version 5 export format to port 5000 of the NetStream server at 4.1.1.1/16. • Router A performs NetStream aggregation in the modes of AS, protocol-port, source-prefix, destination-prefix, and prefix.
[RouterA-ns-aggregation-as] enable [RouterA-ns-aggregation-as] ip netstream export host 4.1.1.1 2000 [RouterA-ns-aggregation-as] quit # Configure the aggregation mode as protocol-port, and then, in NetStream aggregation view, configure the destination address as 4.1.1.1 and the destination UDP port number as 3000 for the NetStream protocol-port aggregation data export.
L2 flow entries been counted : 0 IPL2 flow entries been counted : 0 Last statistics reset time : Never IP packet size distribution (11 packets in total): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .000 .909 .000 .000 .090 .000 .000 .000 .000 .000 .000 .000 .000 .000 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 >4608 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .
Version 9 exported flows number : 0 Version 9 exported UDP datagrams number (failed): 0 (0) destination-prefix aggregation export information: Flow source interface : Not specified Flow destination VPN instance : Not specified Flow destination IP (UDP) : 4.1.1.
Configuring sFlow Sampled Flow (sFlow) is a traffic monitoring technology. As shown in Figure 57, 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 sflow agent { ip ip-address | ipv6 ipv6-address } 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 1. Enter system view. system-view N/A 2. Enter Ethernet interface view. interface interface-type interface-number N/A 3. (Optional.) Set the flow sampling mode. sflow sampling-mode { determine | random } The default mode is determine. 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, this function is disabled. (Optional.
sFlow configuration example Network requirements As shown in Figure 58, configure flow sampling in random mode and counter sampling on Ethernet 1/1 of the device to monitor traffic on the port. Configure the device to send sampled information in sFlow packets through Ethernet 1/3 to the sFlow collector. Figure 58 Network diagram sFlow Collector 3.3.3.2/16 Eth1/3 3.3.3.1/16 Host A 1.1.1.1/16 Eth1/2 2.2.2.1/16 Eth1/1 1.1.1.2/16 Device Server 2.2.2.2/16 Configuration procedure 1.
Verifying the configurations # Display the sFlow configuration and operation information. [Sysname-Ethernet1/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.
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 2 Critical Critical condition. For example, the device temperature exceeds the upper limit, the power module fails, or the fan tray fails. 3 Error Error condition. For example, the link state changes or a storage card is unplugged. 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.
Default output rules for security logs Security logs can only be output to the security log file, and cannot be filtered by source modules and severity levels. Table 17 shows the default output rule for security 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 none Description Example No timestamp is included. % Sysname FTPD/5/FTPD_LOGIN: User ftp (192.168.1.23) has logged in successfully. All logs support this parameter. no-year-date Current date and time without year information, in the format of MMM DD hh:mm:ss:xxx. Only logs that are sent to a log host support this parameter. No timestamp is included. <189>May 30 06:44:22 Sysname %%10FTPD/5/FTPD_LOGIN(l): User ftp (192.168.1.23) has logged in successfully.
Step Command Remarks 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 common logs." 4. (Optional.) Configure the timestamp format. info-center timestamp { boot | date | none } By default, the timestamp format is date. 5. Return to user view. quit N/A 6. Enable log output to the console.
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. 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 common logs." 4. (Optional.
The log file feature saves logs from the log file buffer to a log file every 24 hours. You can adjust the saving interval or manually save logs to the log file. After saving logs into the log file, the system clears the log file buffer. The router supports multiple log files. Each log file has a specific capacity. The log files are named as logfile1.log, logfile2.log, and so on. When the capacity of logfile1.log is reached, the system compresses logfile1.log as logfile1.log.
Managing security logs Security logs are very important for locating and troubleshooting network problems. Generally, security logs are output together with other logs. It is difficult to identify security logs among all logs. To solve this problem, you can save security logs into a security log file without affecting the current log output rules.
Task Command Remarks Display a summary of the security log file. display security-logfile summary Available in user view. By default, the security log file is saved in the seclog directory in the root directory of the storage device. Change the directory of the security log file. Manually save all the contents in the security log file buffer into the security log file. 7. system-view 8.
Step Command (Optional.) Specify the directory to save diagnostic log files. 5. info-center diagnostic-logfile directory dir-name Remarks By default, a diagnostic log file is saved in the diagfile directory under the root directory of the storage device. This command cannot survive a reboot. (MSR2000/MSR3000.) This command cannot survive a reboot or an active/standby switchover. (MSR4000.) • Method 1: Configure the Save the diagnostic logs in the diagnostic log file buffer to a diagnostic log file.
If a different log is generated during the suppression period, the system aborts the current suppression period, outputs suppressed logs and the log number and then the different log, and starts another suppression period. • To enable duplicate log suppression: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable duplicate log suppression. info-center logging suppress duplicates By default, duplicate log suppression is disabled.
Task Command Display a summary of the log buffer (MSR2000/MSR3000). display logbuffer summary [ level severity ] Display a summary of the log buffer (MSR4000). display logbuffer summary [ level severity | slot slot-number ] * Display the configuration of the log file. display logfile summary Clear the log buffer.
Configuration example for outputting logs to a UNIX log host Network requirements Configure the device to output to the UNIX log host FTP logs that have a severity level of at least informational. Figure 61 Network diagram 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.
NOTE: Follow these guidelines while editing the file /etc/syslog.conf: • Comments must be on a separate line and must begin with a pound sign (#). • No redundant spaces are allowed after the file name. • The logging facility name and the severity level specified in the /etc/syslog.conf file must be identical to those configured on the device by using the info-center loghost and info-center source commands. Otherwise, the log information might not be output properly to the log host. d.
[Sysname] info-center source ftp loghost level informational 2. Configure the log host: The following configurations were performed on Solaris. Other UNIX operating systems have similar configurations. a. Log in to the log host as a root user. b. Create a subdirectory named Device in the directory /var/log/, and create file info.log in the Device directory to save logs of Device. # mkdir /var/log/Device # touch /var/log/Device/info.log c. Edit the file syslog.
Configuring EAA Overview Embedded Automation Architecture (EAA) is a monitoring framework that enables you to self-define monitored events and actions to take in response to an event. It allows you to create monitor policies by using the CLI or Tcl scripts. EAA framework EAA framework includes a set of event sources, a set of event monitors, a real-time event manager (RTM), and a set of user-defined monitor policies, as shown in Figure 63.
RTM RTM manages the creation, state machine, and execution of monitor policies. EAA monitor policies A monitor policy specifies the event to monitor and actions to take when the event occurs. You can configure EAA monitor policies by using the CLI or Tcl. A monitor policy contains the following elements: • One event. • At least one action. • At least one user role. • One running time setting. For more information, see "Elements in a monitor policy.
Event type Description SNMP event occurs when the monitored MIB variable's value changes. Each SNMP event is associated with two user-defined thresholds: start threshold and restart threshold. Policy execution is always triggered by crossing of the start threshold and crossing of the restart threshold in turn.
($variable_name) instead of entering a specific value for an argument. EAA will replace the variable name with the variable value when it performs the action. To change the value for an action argument, you modify the value specified in the variable pair instead of editing each affected monitor policy. EAA environment variables include system-defined variables and user-defined variables.
User-defined variables You can use user-defined variables for all types of events. User-defined variable names can contain digits, characters, and the underscore sign (_), but their leading character cannot be the underscore sign. Configuring a user-defined EAA environment variable Configure a user-defined EAA environment variable before you use it in an action. To configure a user-defined EAA environment variable: Step Command Remarks 1. Enter system view. system-view N/A 2.
Step Command Remarks • Configure a CLI event: event cli { async [ skip ] | sync } mode { execute | help | tab } pattern regular-exp • Configure a hotplug event (MSR2000/MSR3000): event hotplug slot slot-number [ subslot subslot-number ] • Configure a hotplug event (MSR4000): event hotplug [ slot slot-number [ subslot subslot-number ] ] • Configure an interface event: event interface interface-type interface-number monitor-obj monitor-obj start-op start-op start-val start-val restart-op restart-op
Step Command Remarks • Configure the action to execute a command: action number cli command-line By default, a monitor policy does not contain any actions. • Configure a reboot action 4. Configure the actions to take when the event occurs. (MSR2000/MSR3000): action number reboot [ subslot subslot-number ] Repeat this step to add up to 232 actions to the policy.
Step Command Remarks By default, the system does not have Tcl policies. 4. Create a Tcl-defined policy and bind it to the Tcl script file. This step enables the Tcl-defined policy. rtm tcl-policy policy-name tcl-filename To revise the Tcl script of a policy, you must suspend all monitor policies first, and then resume the policies after you finish revising the script. The system cannot execute a Tcl-defined policy if you edit its Tcl script without suspending policies.
Displaying and maintaining EAA settings Execute display commands in any view. Task Command Display user-defined EAA environment variables. display rtm environment [ var-name ] Display EAA monitor policies.
In response to this CLI event, EAA executes the policy. You can see the message "rtm_tcl_test is running" and the policy successfully executed message on the terminal screen. CLI-defined policy configuration example Network requirements Configure a policy from the CLI to monitor the event that occurs when a question mark (?) is entered at the command line that contains letters and digits.
Monitoring and maintaining processes HP Comware V7 is a full-featured, modular, and scalable network operating system based on the Linux kernel. Comware V7 software features run the following types of independent processes: • User process—Runs in user space. Most Comware V7 software features run user processes. Each process runs in an independent space so the failure of a process does not affect other processes. The system automatically monitors user processes.
Displaying and maintaining user processes Execute display commands in any view. MSR2000/MSR3000: Task Command Display log information for all user processes. display process log Display memory usage for all user processes. display process memory Display heap memory usage for a user process. display process memory heap job job-id [ verbose ] Display the addresses of memory blocks with a specified size used by a user process.
Kernel threads share resources. If a kernel thread monopolizes the CPU, other threads cannot run, resulting in a deadloop. This feature enables the device to detect deadloops. If a thread occupies the CPU for a specific interval, the device considers that a deadloop has occurred. It generates a deadloop message and reboots to remove the deadloop. To configure kernel thread deadloop detection (MSR2000/MSR3000): Step Command Remarks 1. Enter system view. system-view N/A 2.
Step Command Remarks 1. Enter system view. system-view N/A 2. Enable kernel thread starvation detection. monitor kernel starvation enable By default, the function is disabled. 3. (Optional.) Set the interval for identifying a kernel thread starvation. monitor kernel starvation time interval The default is 120 seconds. (Optional.) Disable kernel thread starvation detection for a kernel thread.
Task Command Display kernel thread deadloop information. display kernel deadloop show-number [ offset ] [ verbose ] [ slot slot-number ] Display kernel thread deadloop detection configuration. display kernel deadloop configuration [ slot slot-number ] Display kernel thread exception information. display kernel exception show-number [ offset ] [ verbose ] [ slot slot-number ] Display kernel thread reboot information.
Support 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 ACDEFHIKLMNOPRST Configuring NTP association modes,65 A Configuring NTP authentication,69 Alarm function configuration example,127 Configuring NTP optional parameters,77 Appendix A Supported NETCONF operations,159 Configuring SNMP basic parameters,108 C Configuring SNMP logging,112 Configuration example for MPLS VPN time synchronization in client/server mode,98 Configuring SNMP notifications,113 Configuration example for MPLS VPN time synchronization in symmetric active/passive mode,100 Co
Enabling synchronous information output,210 Enabling the NQA client,11 NTP symmetric active/passive mode configuration example,82 Enabling the NTP service,65 O Enabling the SNTP service,103 Outputting logs to a log host,206 Establishing a NETCONF session,132 Outputting logs to the console,204 Ethernet statistics group configuration example,124 Outputting logs to the log buffer,206 F Outputting logs to the monitor terminal,205 Filtering data,148 Overview,176 FIPS compliance,131 Overview,169 Ov
Troubleshooting sFlow configuration,198 Terminating another NETCONF session,156 Tracert,3 236
