Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
Ethernet Support Guide: HP-UX 11i v1 and v2 of May 2005 > Chapter 4 Troubleshooting

Diagnostic Flowcharts

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

Table 4-1 “Diagnostic Flowcharts” summarizes the types of network tests in the diagnostic flowcharts.

Table 4-1 Diagnostic Flowcharts

Chart

Type of Test

Purpose

1

Cable and LED Test

Checks that hardware, cables and connectors between your system and card are operational.

2

Link Level Test

Checks communication between link levels on source and target host using linkloop(1M).

3

Network Level Tests

Groups the ARP and ping tests (see Figure 4-3 “Flowchart 3: Network Level Tests” and Figure 4-4 “Flowchart 4: ARP Test” for the details of these tests) at the network level.

4

ARP Test

Verifies that an entry exists for the remote host in your system's ARP cache.

5

ping Test

Checks communication between network layers on the source and target host.

6

Transport Level Test

Checks communication between transport layers on source and target host using telnet and ftp sessions.

7

Bridge/Gateway Loopback Test

Checks general network connections through a gateway.

8

Configuration Tests

Verifies configuration of network interface on a host using ioscan(1M), lanscan(1M), netfmt(1M), lanadmin(1M) and ifconfig(1M).

9

ioscan and lanscan Tests

Verifies configuration of network interface on a host.

10

netfmt and lanadmin Tests

Verifies configuration of network interface on a host.

11

ifconfig Test

Verifies configuration of network interface on a host.

 

Flowchart 1: Cable and LED Test

Use the process in this flowchart to ensure that the hardware, cables and connectors between your system and card are operational.

Figure 4-1 Flowchart 1: Cable and LED Test

Flowchart 1: Cable and LED Test

Flowchart 1 Procedures

The procedures in Flowchart 1 are:

  • Check the dmesg/syslog output and look for error messages pertaining to gelan/igelan or btlan. Also, check the nettl log messages. If there are errors, check the card installation and reset or re seat the card. The following log files are created by NetTL:

    • For releases prior to HP-UX 11i: nettl.LOG-00 and nettl.LOG-01

    • For release HP-UX 11i and later: nettl.LOG000 and nettl.LOG001

  • Verify the status of the card’s LEDs. If the Link LED = OFF or for gelan, all Speed LEDs = ON, check the card installation and reset and/or re seat the card. If a card’s LEDs are now displayed correctly, continue to Link Level Test.

  • If all Speed LEDs = OFF or Link LED = Flashing, check for an incorrect or faulty network cable or connector. Ensure that your switch is capable of the appropriate speed (1000 Mbit/s for Gigabit and 10/100 Mbit/s for Fast Ethernet) operation. Ensure that the switch (or immediate link partner) and card are set to the same autonegotiation settings. Then, go to Configuration Tests (Flowchart 8). Otherwise, if the Link LED or one of the Speed LEDs is on, continue to the Link Level Test (Flowchart 2).

NOTE: On a Gigabit Ethernet card, if both Link and Activity LEDs are on and there is no network connectivity, it could mean that the I/O cage is not seated well. Remove and re seat the entire PCI-X I/O cage and reboot.

Flowchart 2: Link Level Test

Use the process in this flowchart to check communications between link levels on the source and target host by using linkloop(1M).

Figure 4-2 Flowchart 2: Link Level Test

Flowchart 2: Link Level Test

Flowchart 2 Procedures

The procedures in Flowchart 2 are:

  • Enter linkloop(1M) to the remote host’s MAC address. If the linkloop result is successful, continue to the Network Level Tests (Flowchart 3). Otherwise, note which error was returned.

  • If loopback failed and the error message returned was “Address has bad format” or “Not an individual address”, correct the link level address with the proper station address format and value and repeat the Link Level Test.

  • Otherwise, loopback failed because the remote host did not respond. Double-check the remote host’s MAC address or choose another remote host, and re-enter linkloop(1M). If linkloop is now successful, continue to Network Level Tests (Flowchart 3). You may also want to call the node manager of the remote host that did not respond (if this was the case). If linkloop fails, go to Configuration Tests (Flowchart 8).

  • Note that linkloop cannot be used to test connectivity between end stations if those stations are separated by a gateway or router. To test connectivity between stations under these circumstances, run the linkloop test between the router or gateway and each of the end stations independently, then verify network level connectivity by using ping between the end stations. If the end stations cannot communicate with each other, but they can each communicate with the router or gateway, then verify the routing tables in the router or gateway.

  • On HP-UX 11i, linkloop cannot send packets larger than 1500 bytes even if the MTU size is set greater than 1500. This is a known issue, which is fixed on HP-UX 11i v2 (11.23). On HP-UX 11i, linkloop can however receive packets larger than 1500 bytes if, for example, the packets are sent from an HP-UX 11i v2-based system.

Flowchart 3: Network Level Tests

Use the process in Flowchart 3 to validate arp(1M) entries and remote host availability. This process also checks communication between network layers (see Figure 4-4 “Flowchart 4: ARP Test” ) on source and target host using ping(1M) (see Figure 4-5 “Flowchart 5: ping Test”).

Figure 4-3 Flowchart 3: Network Level Tests

Flowchart 3: Network Level Tests

Flowchart 3 Procedures

The procedures in Flowchart 3 are:

Flowchart 4: ARP Test

Use the process in Flowchart 4 to validate arp(1M) entries and remote host availability.

Figure 4-4 Flowchart 4: ARP Test

Flowchart 4: ARP Test

Flowchart 4 Procedures

  • Enter ping(1M) to the remote host’s IP address so that an ARP entry is added. Whether or not ping is successful, proceed to the next step.

  • Use arp(1M) to verify that an entry exists for the remote host in your system's ARP cache, by entering arp hostname.

  • If there is no ARP entry for the remote host, check to see if the remote host is up. If not, bring up remote host and continue to the ping Test (Figure 4-5 “Flowchart 5: ping Test”).

  • If the ARP entry is correct or complete, continue to ping Test. Otherwise, use arp(1M) to enter the correct station address of the remote system and continue to the ping Test (Figure 4-5 “Flowchart 5: ping Test”).

Flowchart 5: ping Test

Use the process in Flowchart 5 to check communication between network layers on the source and target host by using ping(1M).

Figure 4-5 Flowchart 5: ping Test

Flowchart 5: ping Test

Flowchart 5 Procedures

The procedures in Flowchart 5 are:

  • Enter ping(1M) to the remote host. If ping is successful, continue to the Transport Level Test (Flowchart 6).

  • If ping is not successful, enter netstat -in to verify MTU size. Ensure that the MTU size is the same on both the local and remote hosts (9000 for Jumbo Frames and 1500 for standard frames) by entering lanadmin -M new_mtu ppa, and repeat the ping Test. Jumbo Frames are supported in Gigabit Ethernet only, not in Fast Ethernet.

  • If ping is still not successful and you are either (1) not using Jumbo Frames or (2) using Jumbo Frames with the correct speed setting, continue to the next flowchart (Figure 6-6) to validate the network, remote host and configuration settings.

  • If the link speed is not appropriate (1000 Mbit/s for Gigabit and 10/100 Mbit/s for Fast Ethernet), set it with lanadmin -X speed ppa, and repeat the ping Test.

Flowchart 5 (continued)

Figure 4-6 Flowchart 5: ping Test (continued)

Flowchart 5: ping Test (continued)

Flowchart 5 (continued) Procedures

The procedures in this part of the Flowchart are:

  • If there is a network unreachable error, go to Configuration Tests (Flowchart 8).

  • If there is no response from ping, and you are using Jumbo Frames (Gigabit Ethernet only), verify that the switches in the path support Jumbo Frames, making sure the path MTU is the same (9000 maximum) from the source host to the destination host. Otherwise, reconfigure the network path and repeat the ping Test. If you are not using Jumbo Frames, or the switches and path MTU are correctly set for Jumbo Frames (9000 bytes), go to the Cable and LED Test (Flowchart 1).

  • If you receive an unknown host error, add the missing host name and repeat the ping Test.

  • If you receive “error=SendTo: No route to host,” use route(1M) to add a route table entry for the missing host and repeat the ping Test. Otherwise, call your HP representative.

Flowchart 6: Transport Level Test

Use the process in Figure 4-7 “Flowchart 6: Transport Level Test” to check communications between transport layers on the source and target host by using telnet and ftp sessions.

Figure 4-7 Flowchart 6: Transport Level Test

Flowchart 6: Transport Level Test

Flowchart 6 Procedures

The procedures in Flowchart 6 are:

  • Enter telnet(1M) to a remote host. If the process is successful, stop.

  • If the process is not successful, try to establish an ftp link to a remote host. Unlike telnet, ftp does not use a pseudoterminal (pty) driver on your system. This will determine if pty is why telnet failed. If ftp is successful, call your HP representative to determine why you have a problem with pty.

  • If ftp fails, check to see if TCP is configured on both hosts by verifying the /etc/protocols file. Telnet and ftp work at the transport layer and require TCP. If TCP is not configured, configure it now and repeat the Transport Level Test ( Figure 4-7 “Flowchart 6: Transport Level Test”).

  • If TCP is installed on both hosts, telnet to another host and use netstat(1M) to check for lost packets. If the network is congested, you may need to reconfigure the network. If network congestion is not the cause of the problem, more detailed network diagnostics are required. In either case, call your HP representative.

Flowchart 7: Bridge/Gateway Loopback Test

Use the process in Figure 4-8 “Flowchart 7: Bridge/Gateway Loopback Test” to check the general network connections through a gateway .

Figure 4-8 Flowchart 7: Bridge/Gateway Loopback Test

Flowchart 7: Bridge/Gateway Loopback Test

Flowchart 7 Procedures

The procedures in Flowchart 7 are:

  • Enter ping(1M) from a known good host through a gateway to another known good host. This will test connectivity through the bridge/gateway level. If successful, run netstat -r and examine the route table on the problem host and all hosts in the path. If necessary, correct the routing table and go to Network Level Tests (Figure 4-3 “Flowchart 3: Network Level Tests”).

  • If ping fails, examine the gateway to see if it is an HP or non-HP product. If non-HP, see networking documentation for that product. If HP, enter ifconfig(1M) for all interfaces on gateway or host (see Configuration Tests, Figure 4-9 “Flowchart 8: Configuration Tests”, for more details on ifconfig).

  • If ifconfig does not show the UP parameter as output for the gateway, enter netstat -i to check the status of network interfaces. An asterisk (*) indicates that the interface is down. If the network interface is down, configure the interface up and repeat the Bridge/Gateway Test (Flowchart 7). If all interfaces are up, continue to the Configuration Tests (Flowchart 8) and test all interfaces on the gateway.

Flowchart 8: Configuration Tests

Use the process in Figure 4-9 “Flowchart 8: Configuration Tests” to verify configuration of a network interface on a host by using ioscan(1M), lanscan(1M), netfmt(1M), lanadmin(1M) and ifconfig(1M).

Figure 4-9 Flowchart 8: Configuration Tests

Flowchart 8: Configuration Tests

Flowchart 8 Procedure

This procedure verifies the configuration of a network interface on a host using ioscan(1M), lanscan(1M), netfmt(1M), lanadmin(1M) and ifconfig(1M).

Flowchart 9: ioscan and lanscan Tests

Use the process in Figure 4-10 “Flowchart 9: ioscan and lanscan Tests” (Flowchart 9) to verify the configuration of a network interface on a host using ioscan(1M) and lanscan(1M).

Figure 4-10 Flowchart 9: ioscan and lanscan Tests

Flowchart 9: ioscan and lanscan Tests

Flowchart 9 Procedures

The procedures in Figure 4-10 “Flowchart 9: ioscan and lanscan Tests” (Flowchart 9) are:

  • Enter ioscan(1M) as follows:

    ioscan -kfd drivername

    In this command, drivername is either btlan, gelan or igelan.

    Verify that the output from ioscan shows that the card is “CLAIMED” by the system.

    IMPORTANT: Do not proceed to the next step until this step has been done! It is possible for a card’s bulkhead LED to indicate that the card is “present” when, in fact, ioscan will show that it is not. The cause is a poorly seated PCI-X slot assembly that allows power to the LED, but there is a poor, or nonexistent, connection to the PCI-X bus. The fix is to remove and re seat the appropriate portion of the I/O cage, and then reboot.
  • If the card is claimed, enter lanscan(1M) and check to see if the hardware state display shows UP. If so, go to Cable and LED Test (Flowchart 1). If not, continue to the logging function of the netfmt and lanadmin Test (Flowchart 10).

  • If the card is not claimed, enter: what /stand/vmunix | grep drivername

    In this command, drivername is one of the previous drives. Verify that the output is similar to the output documented in the latest Release Notes for your Gigabit Ethernet product. Use the name of the running kernel image file in place of /stand/vmunix as appropriate.

  • If the driver is displayed, check to see if the dmesg/syslog output shows error messages pertaining to btlan/gelan/igelan. Also, check nettl log messages. If there are errors, check the card installation and reset or re seat the card, and repeat this test. Otherwise, call your HP representative.

    Note that NetTL creates the following log files:

    • For releases prior to HP-UX 11i: nettl.LOG-00 and nettl.LOG-01

    • For release HP-UX 11i and later: nettl.LOG000 and nettl.LOG001

  • If the driver is not displayed, install it using swinstall(1M) and:

    • For pre-11.23 systems:

      Regenerate the kernel, reboot the system, and repeat this test.

    • For 11.23 systems:

      Use the appropriate kernel configuration commands.

Flowchart 10: netfmt and lanadmin Tests

Use the process in Figure 4-11 “Flowchart 10: netfmt and lanadmin Tests” (Flowchart 10) to verify the configuration of the network interface on a host using netfmt(1M) and lanadmin(1M).

Figure 4-11 Flowchart 10: netfmt and lanadmin Tests

Flowchart 10: netfmt and lanadmin Tests

Flowchart 10 Procedures

The procedures in Figure 4-11 “Flowchart 10: netfmt and lanadmin Tests” (Flowchart 10) are:

  • Enter netfmt(1M) and view the error and disaster log messages. For example:

    netfmt -vf /var/adm/nettl.LOG00

    It will help to use the time stamp to find proper logs. Ensure you are looking at Ethernet information.

    Note that the names of the NetTL log files are:

    • For releases prior to HP-UX 11i: nettl.LOG-00 and nettl.LOG-01

    • For release HP-UX 11i and later: nettl.LOG000 and nettl.LOG001

  • If the problem is solved, continue to the ifconfig Test (Flowchart 11).

  • If the problem persists, run lanadmin(1M) to reset the card.

  • If the reset is successful, go to Link Level Test (Flowchart 2). Otherwise, reset the card once more; if it is still not successful, call your HP representative.

Flowchart 11: ifconfig Test

Use the process in Figure 4-12 “Flowchart 11: ifconfig Test” (Flowchart 11) to verify configuration of the network interface on a host using ifconfig(1M).

Figure 4-12 Flowchart 11: ifconfig Test

Flowchart 11: ifconfig Test

Flowchart 11 Procedures

The procedures in Flowchart 11 are:

  • Enter ifconfig(1M) on the interface you want to configure to ensure that the interface is enabled. For example:

    ifconfig lan1 192.6.1.17 netmask 255.255.255.0 up

    Next, enter ifconfig interface to test and verify flag setting is UP and correct IP address is displayed. For example:

    ifconfig lan1<UP,BROADCAST,RUNNING,MULTICAST,CKO>

  • If the IP and flags are correct, verify there is an entry for the card interface in /etc/rc.config.d/netconf. If so, go to Network Level Tests (Flowchart 3). Otherwise, add the correct interface parameters to /etc/rc.config.d/netconf file and reboot. If the flags are incorrect, correct them with ifconfig and repeat this test. Otherwise, if ifconfig is not successful and error messages appear, correct them accordingly and repeat this test.

  • If you cannot correct the errors, call your HP representative.

Network Level Test for Jumbo Frames (Gigabit Ethernet only)

If you are using any of the Fast Ethernet cards, you may ignore this section. Jumbo Frames only apply to Gigabit Ethernet.

Test Procedure

Within a LAN (that is, not across a router or layer 3), MTUs of all the end stations must be set equal to each other, and greater than or equal to 1500. You can verify this using the lanadmin -m administrative command (on HP-UX systems). The MTU for bridges and layer 2 switches in the LAN must be set to the MTU value of the end stations, or more. To test for Jumbo Frames, follow these steps:

  1. Ensure that the MTU of all end stations is greater than, or equal to, 1500.

  2. Check the IP level connectivity by using the ping(1M) command with a message size greater than 1480. For example:

    ping 192.6.20.2 2000

  3. If there is a response to the ping command, Jumbo Frames is configured correctly.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2003-2005 - , Hewlett-Packard Development Company, L.P.