Diagnostic Flowcharts

A.

Execute: ping to remote host. Using ping(1M), send a message to the remote host to which you are having problems connecting. For example:

ping spiff

B.

ping successful? A message is printed to stdout for each ping packet returned by the remote host. If packets are being returned, your system has network level connectivity to the remote host. Note what percentage of the total packets are lost, if any. Losing ten percent or more may indicate the network or remote host is extremely busy. You may also find it useful to note the round-trip transmission times. Periodically high transmission times may indicate that the network or remote host is extremely busy. Consistently high transmission times may indicate the local host is extremely busy. If a message is not returned after executing ping, ping is not successful. Do Cntrl C to stop the ping output.

C.

Network unreachable? If yes, go to flowchart 3 to display connection status using the lanscan(1M) command.

D.

Command hangs? If a message is not returned after executing ping, go to flowcharts 2 through 7, referring back to flowchart 1 (ping) until you have corrected the problem.

E.

Unknown host? If you receive this message, go to step F.

F.

Correct BIND, YP or hosts configuration. Add the missing host name and start again with flowchart 1.

G.

No route to host? If Error= Sendto: No route to host, go to Step H. Otherwise, call your HP representative for help.

H.

Add route table entry. Using route, add a route table entry for that host. Refer to the route(1M) online man page for more details. Start again with flowchart 1.

A.

Check Power outlet. Ensure the power cord is plugged in to a live outlet.

B.

Test Error Message on Screen? At the HP-UX prompt, type the dmesg command, and look for an error message. Does the dmesg output show an error message from btlan5? If not, go to step D.

Note: Even if the Test LED is OFF, a card problem is still possible if either of the following two messages appear:

btlan5: Error: Motherboard failed to complete reset.

btlan5: Error: Motherboard failed selftest;error code= 0x?

C.

Check card installation. If dmesg reported an error message from btlan5, reset card according to Steps D through G in flowchart 4. If problem persists, call HP. Go back to flowchart 1.

D.

Check status of Link LED.

E.

Link LED = OFF? If it is off, proceed to step F.

If Link LED = ON, proceed to step G.

F.

If Link LED = OFF, check connection to hub or switch. Ensure switch is not autonegotiating. Ensure hub or switch is 10Base-T or 100Base-TX. Reset card according to Steps D through G in flowchart 4. Go back to flowchart 1.

G.

Do link speed and duplex mode match switch? If they do, proceed to flowchart 3.

H.

If Link speed and duplex mode do not match what you expect, set attached hub or switch to the correct link speed and duplex mode, and enable autonegotiation. Reset card according to Steps D through G in flowchart 4. Go back to flowchart 1.

Title not available (Flowchart 3 Procedures)

A.

Execute: lanscan. Enter the lanscan command to display information about LAN cards that are successfully bound to the system. See the lanscan online manpage for more detailed information.

B.

Is your interface displayed? lanscan shows information about every LAN card in the system backplane. The Hardware Path of one of the entries should correspond to the PCI 10/100Base-TX card slot multiplied times 4. For example, a hardware path of 32 corresponds to an PCI 10/100Base-TX card in slot 8.

C.

Hardware up? The hardware state is operational if up is displayed for the 10/100Base-TX card under the Hardware State heading. If it is, continue to flowchart 5. If not, go to D.

D.

Run ioscan. ioscan will scan the system hardware and list the results. If you execute ioscan -f, output similar to the following will be displayed:

Class I H/W Path Driver S/W State H/W Type Description ======================================================================== bc 0 root CLAIMED BUS_NEXUS bc 1 8 ccio CLAIMED BUS_NEXUS I/O Adapter bc 2 10 ccio CLAIMED BUS_NEXUS I/O Adapter ext_bus 0 10/0 c720 CLAIMED INTERFACE GSC built-in Fast/Wide SCSI Interface bc 3 10/4 bc CLAIMED BUS_NEXUS Bus Converter tty 0 10/4/0 mux2 CLAIMED INTERFACE MUX lanmux 2 10/4/4 lanmux0 CLAIMED INTERFACE HP J2146A - 802.3 LAN lan 1 10/4/4.1 lan3 CLAIMED INTERFACE ba 0 10/8 GSCtoPCI CLAIMED BUS_NEXUS PCI Bus Bridge lan 2 10/8/1/0 btlan5 CLAIMED PCI (10110009) lan 3 10/8/2/0 btlan5 CLAIMED PCI (10110009) ba 1 10/12 bus_adapter CLAIMED BUS_NEXUS Core I/O Adapter ext_bus 2 10/12/0 CentIf CLAIMED INTERFACE Built-in Parallel Interface ext_bus 1 10/12/5 c720 CLAIMED INTERFACE Built-in SCSI target 3 10/12/5.2 tgt CLAIMED DEVICE disk 2 10/12/5.2.0 sdisk CLAIMED DEVICE TOSHIBA CD-ROM XM-5401TA target 3 10/12/5.7 tgt CLAIMED DEVICE ct1 1 10/12/5.7.0 sct1 CLAIMED DEVICE Initiator lan 0 10/12/6 lan2 CLAIMED INTERFACE Built-in LAN ps2 0 10/12/7 ps2 CLAIMED INTERFACE Built-in Keyboard/Mouse processor 0 32 processor CLAIMED PROCESSOR Processor processor 1 34 processor CLAIMED PROCESSOR Processor memory 0 49 memory CLAIMED MEMORY Memory

E.

Is driver in kernel? If the driver has not been generated into the kernel, ioscan output will be:

ioscan -f Class I H/W Path Driver S/W State H/W Type Description =================================================================== unknown -1 10/4/4 UNKNOWN UNCLAIMED INTERFACE

The class and driver fields alone will indicate "unknown" status if the kernel has not been generated. If the driver has not been generated, continue to step H. If the driver is in the kernel, go to step G.

F.

Verify or edit /stand/system and regen kernel. Verify/edit /stand/system contains the btlan5 keyword. If not, see "Creating a New Kernel" in chapter 3 of the Installing and Administering LAN/9000 Software manual for instructions on how to edit /stand/system to create a new kernel.

G.

Check hardware. Verify that the network card is seated correctly and that it is operational.

H.

Reboot the system.

I.

Problem fixed? If you have found the 10/100Base-TX card problem, stop. If not, start again with flowchart 1.

A.

Execute: netfmt. Use the netfmt command to view log data (error and disaster messages). An example command is shown below.

netfmt -v -f /var/adm/nettl.LOG00 | more

B.

Check causes and actions on display in the formatted log output. Use the time stamp to find the proper logs. Ensure that you are looking at the 10/100Base-TX information.

C.

Problem solved? If yes, go to flowchart 1. If not, continue with step D.

D.

Execute lanadmin. Run lanadmin(1M). For a complete description of this command, refer to the lanadmin(1M) on-line manual page.

E.

Select LAN from Menu. Select lan from the menu to enter LAN Interface Diagnostic.

F.

Select the NMID command and enter the 10/100Base-TX NMID. You can use the lanscan command to find the current NMID for 10/100Base-TX. The NMID you enter becomes the current device to be tested.

G.

Reset the card according to Steps D through G in flowchart 4. Using the reset command in lanadmin re-executes the LAN card self-test.

H.

Reset successful? The reset is successful if no errors are displayed as a result of the reset command. If the self-test was successful, the problem may be that you are not connected to the 10/100Base-TX network. Correct the problem and verify the resolution by continuing with flowchart 1. Otherwise, go to flowchart 4A.

A.

Execute: netfmt. Use the netfmt command to view log data (error and disaster messages). An example netfmt command is shown below:

netfmt -v -f /var/adm/nettl.LOG00 | more

Extend the search to LOG01 as information may have rolled (overflowed) into this file from LOG00.

B.

Check causes and actions on display in the formatted log output. Use the time stamp to find the proper logs. Ensure that you are looking at the 10/100Base-TX information.

C.

Problem solved. If yes, go to flowchart 1. If not, contact your HP representative.

A.

Execute: ifconfig <interface> <IP address> up. Execute ifconfig on the interface you want to configure in order to ensure that the interface is enabled. For example, to configure the 10/100Base-TX interface lan1, enter:

ifconfig lan1 192.6.1.17 up

For more examples of the ifconfig command, refer to the ifconfig(1M) online man page.

B.

Execute: ifconfig <interface>. Execute ifconfig without the up parameter again on the interface you want to test to check the flag setting for the up parameter. For example, to check the 10/100Base-TX interface lan1, enter:

ifconfig lan1

C.

ifconfig successful? ifconfig is successful if the output shows the correct Internet address and the flags: <UP,BROADCAST, NOTRAILERS, RUNNING>.

Note: Make sure the UP flag is displayed.

D.

Are flags correct? If flags are not correct, use the ifconfig command to correct them. If they are correct, go to step F.

E.

Correct ifconfig flag settings. If ifconfig returns an incorrect flag setting, re-execute the command with the proper setting. For more information, refer to the ifconfig(1M) online man page. Start again with flowchart 5, as necessary.

F.

Any error message returned? If ifconfig is not successful, and an error message appears, go to Step G. If no error messages appear, contact your HP representative.

G.

Correct problem according to the message received. If you received an error message, make the appropriate corrections stated in the message and then begin this procedure again.

H.

ifconfig entry in /etc/rc.config.d/netconf? Check that there is an entry in the /etc/rc.config.d/netconf file for your 10/100Base-TX card.

I.

Add ifconfig command to /etc/rc.config.d/netconf file. Add the ifconfig command to /etc/rc.config.d/netconf, and reboot. For more information, refer to the ifconfig(1M) online man page. Go to flowchart 1 to verify that the problem has been solved.

A.

Host entry in ARP cache? Using arp, check that an entry exists for the remote host in your system's ARP cache. For example:

arp spiff

B.

Remote host up? If there is no ARP cache entry for the remote host, first check that the remote host is up. If not, the remote host has not broadcast an ARP message, and that probably is why there is no entry in the ARP cache.

C.

Bring-up remote host. Have the node manager of the remote host bring that system up and start again with flowchart 1.

D.

Entry complete? Perhaps there is an ARP cache entry, but it is wrong or not complete. If the entry is complete, go to step F.

E.

Use arp to complete entry. Using arp, enter the correct Station Address. For more information, refer to the arp(1M) online man page. Start again with flowchart 1.

F.

ping local host. Using ping, do an internal loopback on your own system. In other words, ping your own system.

If the internal loopback is successful, your system is operating properly to the Network Layer (OSI Layer 3). In addition, you know an ARP cache entry for the remote host exists on your system. Start again with flowchart 1.

A.

Execute: linkloop to remote host. Enter the NMID of your 10/100Base-TX card and link level address (station address) of the remote host in hexadecimal form (preceded by "0x"). Execute lanscan (1M) on the local system to find the NMID and obtain the link level address (station address) of the remote host. For more information on linkloop, refer to the linkloop(1M) online man page.

B.

linkloop successful? If the test was successful, go to flowchart 1 to verify that the problem is solved. Network connectivity is o.k. through the Link Layer (OSI Layer 2). If not successful, note which error was returned and continue with this flowchart.

C.

Loopback failed: Address has bad format. The link level address is not correct. Go to F.

D.

Loopback failed: Not an individual address. The link level address is not correct. The first hexadecimal digit has its high order bit set (if the value is equal to or greater than 8, it is set). This means it is a multicast or broadcast address, which is not allowed. The address must be unique to one remote host. Go to F.

E.

Loopback failed. The remote host did not respond. Go to G.

F.

Correct the link address parameter. Change the link level address to an allowed value and start again with flowchart 7.

G.

Choose a different remote host; re-execute linkloop. Restart flowchart 7 using a different remote host.

H.

linkloop successful? If the test was successful, go to step I. Network connectivity is o.k. through the Link Layer (OSI Layer 2). If not successful, the problem may be with the remote system. Go to flowchart 6.

I.

Check remote host's connectivity to 10/100Base-TX. Contact the node manager of the remote host. Check that the host is configured correctly and that its network interface is up. If necessary, use flowchart 1 to verify configuration of the remote host.

A.

Execute: telnet to remote host. Try to establish a telnet connection to the remote host.

B.

Successful? If your telnet attempt was successful, stop. The connection is o.k. through the Transport Layer (OSI Layer 4).

C.

Execute: ftp to remote host. Unlike telnet, ftp does not go through a pseudoterminal driver (pty) on your system. This step tests to see if the pty is why telnet failed.

D.

Successful? If ftp is successful, you likely have a problem with a pty on your system. Contact your HP representative.

E.

TCP not configured on local nor remote host? Neither telnet or ftp will work if TCP is not configured on either side of the connection. Check the /etc/protocols file on both hosts to be sure TCP is installed and configured.

F.

Network congested? If TCP is installed on both hosts, do a file transfer to another remote host on the network. Use netstat(1) to check for lost packets.

If network congestion is not the cause, more detailed diagnostics are required. Again, contact your HP representative.

G.

Configure TCP. If necessary, install TCP on either or both hosts. Start again with this flowchart.

A.

Execute: ping from known good host through gateway to known good remote host. This will test gateway connectivity to the remote network.

B.

Successful? If the executing ping returned successfully, the problem may exist in the routing table for the problem host. Go to C.

C.

Check route table on problem host and all hosts in between. Execute netstat -r to see a route table.

D.

Examine gateway. If the gateway is an HP 9000, go to G. If it is not, go to F.

E.

Correct route tables. Ensure that the proper IP/Internet addresses are assigned in the Destination and Gateway fields. If you are using subnetting, make sure that the destination is what you expect: a network or a host. Go to flowchart 1 to verify that the problem is solved.

F.

Non-HP 9000 or other vendors. Refer to networking documentation. Refer to the documentation that came with the gateway for additional diagnostics.

G.

If HP 9000, execute ifconfig on gateway host. Execute ifconfig for all network interfaces on the gateway.

H.

Network interface up? If the output from ifconfig does not include the UP parameter, the network interface is down. Execute netstat -i to check the status of the network interfaces. An asterisk (*) indicates that the interface is down. If the network interface is down, go to I.

If the network interfaces are UP, start again with flowchart 3. Using flowchart 3, test all network interfaces on the gateway.

I.

Configure interface up. Execute ifconfig on each interface to bring it up. Start again with flowchart 1. Using flowchart 1, test all network interfaces on the gateway.