 |
» |
|
|
|
|  | |
Below is a summary of the types of network tests in the diagnostic flowcharts.
To diagnose your problem, first check the connections and configuration
on your system (Flowcharts 1 through 5). If this does not solve
your problem, use flowcharts 6 through 11 to test/verify connectivity
with a remote system. - 1, 2 & 3
Configuration Test - 4 & 5
Network Level Loopback Test - 6
Transport Level Loopback Test (using Internet Services) - 7
Link Level Loopback Test - 8
LAN Connections Test - 9 &10
Gateway Remote Loopback Test - 11
Subnet Test
Configuration Test: Verifies the configuration
of the network interface on a host using the lanscan(1M), and ifconfig(1M) commands. Network Level Loopback Test: Checks roundtrip
communication between Network Layers on the source and target host
using the ping(1M) diagnostic. Transport Level Loopback Test: Checks
roundtrip communication between Transport Layers on the source and
target host using Internet Services telnet and ftp commands. Link Level Loopback Test: Checks roundtrip
communication between Link Levels on the source and target host
using the linkloop(1M) diagnostic. LAN Connections Test: Checks the connections
between the LAN media and any component between the LAN media and
individual LAN cards. Gateway Remote Loopback Test: Checks
general network connections through a gateway. Subnet Test: Verifies the correct use
of subnets. The loopback tests shown in Figure 4-1 “Loopback Tests” are used to isolate a network communication problem
that may be software- or hardware-related. In any case, you should
first have checked that the problem is not due to a recent configuration
change. The network level loopback test, ping(1M), commonly is tried first. It is fast, efficient,
and it does not require super-user privileges. If the connection
passes this test, you know the problem is at OSI Layer 4 or above.
Go on to the transport level loopback test. The Transport Level Loopback Test can be implemented using
Internet Services. In this case, you use telnet and ftp to systematically focus on a problem. If the network level loopback test failed, the problem is
in OSI Layer 3 or below. In this case, continue with the link level
loopback test, linkloop(1M), to isolate a problem to OSI Layer 2 or below. netstat(1M) reports network and protocol statistics regarding
traffic and the local LAN interface. As shown in Figure 4-2 “Networking Software
Statistics”, there are many options to netstat(1M). The options that are most useful are those which
display information that is not available through other commands such
as ping and lanadmin, for example, -a and -r options. You can also use the lanadmin(1M) command to obtain LAN driver statistics. For more
detailed information on these diagnostics, refer to the
netstat(1M) and lanadmin(1M) man pages. Flowchart 1: Configuration Test | |
- A.
Execute: lanscan. Execute lanscan to display information about LAN cards that are
successfully bound to the system. For example, to check the cards on /stand/vmunix, enter: - B.
All interfaces configured? lanscan is successful if the output shows information
about every card in the hardware backplane. - C.
Execute ioscan. Execute the ioscan(1M) command to check for bind errors. - D.
bind errors? If a bind error
exists, check that the hardware has been properly installed. - E.
Correct driver in /stand/system file? Refer
to "Creating a New Kernel for All HP 9000 Systems" in
chapter 3 for a list of LAN drivers. - F.
Add correct driver and regen. Edit
the /stand/system file to contain the correct driver for your system
type.
Flowchart 2: Configuration Test continued | |
- A.
Execute: ifconfig <interface>. Execute ifconfig on the interface you want to test. For example,
to check LAN interface lan0, enter: - B.
ifconfig successful? ifconfig is successful if the output shows the correct
Internet address and the flags, typically: UP,BROADCAST,RUNNING. - C.
Any error message returned? If ifconfig is not successful, and an error message appears,
go to Flowchart 3. Flowchart 3 shows common error messages and what
to do for each. - D.
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) man page. Start again with Flowchart 2, as necessary. - E.
Execute: netstat -i. If ifconfig is successful, you know the network interface
has been configured correctly. Using netstat, you can return statistics which show the interface
is operational. Enter: netstat statistics give a quick check of key operating parameters.
For instance, if the Opkts value does not change after attempting the file
transfer, packets are not being transmitted. Similarly, if the Ipkts value does not change, packets are either not
being received by the local node or are not being sent by the remote node,
which may not be receiving your transmissions. - F.
Interface name correct? Verify
that the name for your interface is what you expect. See the ifconfig(1M) man page. - G.
Correct encapsulation using ifconfig. Use
the ifconfig command to correct the encapsulation method of
your interface. For more information, refer to the ifconfig(1M) man page. Go to E. - H.
Suspect LAN card I/O problems? If
the statistics indicate possible LAN card problems, go to J, otherwise go
to Flowchart 4. - I.
Execute: lanadmin. Use lanadmin to ensure the LAN card is operational. If the
values of the Ierrs and Oerrs fields increase substantially during a file transfer
attempt, this can indicate transmission or reception problems.
Refer to "LAN Interface Card Statistics" in this
chapter for more information. - J.
Problem resolved? If you have
found and corrected the LAN card problem, stop. If not, call your
HP representative for help. Be prepared to discuss the problem as
described in "Contacting your HP Representative" at
the end of this chapter.
Flowchart 3: Configuration Test continued | |
- A.
ifconfig not found. The command
has been relocated on the system, deleted, or /usr/sbin is not in your PATH. - B.
Restore /etc/ifconfig from media.
You can restore ifconfig from the last good backup tape or your install/update
tape. Go to Flowchart 2. - C.
Bad system call. Networking
is not configured into the HP-UX kernel. - D.
Reconfigure HP-UX kernel to include LAN/9000 software. Edit
the /stand/system file to include LAN/9000 software. Refer to chapter
3 for a list of LAN drivers. - E.
No such interface name. The
interface name passed to ifconfig does not exist on the system. Check spelling and
names of interfaces on the system using lanscan. If you have more than one LAN card, make sure the number of
LAN cards has been configured into the kernel and that an ifconfig command has been executed for each. - F.
Execute lanscan. Execute lanscan to display information about the LAN cards in
your system. - G.
Find correct interface name.
Using the correct interface name, start again with Flowchart 1. - H.
Is Hardware State UP? Verify
the state of the hardware with the output from the lanscan command. If the Hardware State is up go to I,
otherwise go to H. - I.
Execute lanadmin. Use the lanadmin command to reset the LAN card. Go to Flowchart
2. - J.
Check for the plumbing error: Bad file
number. If you see this error, the TCP/IP stack has not
yet been initialized. - K.
Initialize the TCP/IP stack. Execute
the command /sbin/init.d/net.init start. - L.
Check the status of the network.
Use the command netstat -in. Make sure that the loopback interface lo0 appears in the display. - M.
Check the loopback interface. Use
the command ping 127.0.0.1. If you cannot ping the loopback interface, call
HP. If the ping is successful, go to Flowchart 2. - N.
Any other error message. If
you received an error message not listed on this flowchart, interpret
the message and take the appropriate action. If you need assistance,
call your HP representative. Be prepared to discuss the problem
as described in "Contacting Your HP Representative" in
chapter 5, "LAN Resources."
Flowchart 4: Network Level Loopback Test | |
- A.
Execute: ping to remote host. Using ping(1M), send a message to the remote host with which
you are having problems connecting. For example, suppose the remote host
is known as 192.6.20.2. Enter: ping 192.6.20.2
| | | |  | NOTE: HP recommends using the IP address, rather than the
hostname, as part of the problem may be an error in the /etc/hosts file or connectivity with a name server. | | | | |
- B.
ping successful? A message
is printed on 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. You may find it useful to 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. If, over a one-day
period, ping reports a packet loss that you feel is unacceptable,
yet connectivity remains, report this to your HP representative. 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. Make sure that
the network event logging masks are not set to values which can
impair system performance (such as DEWRP). - C.
Network unreachable? If so,
check the status of the local LAN interface first. - D.
Local LAN interface up? Execute ifconfig on the local interface to be sure it is configured
up. - E.
Configure interface up. If
you find the local interface is not up, execute ifconfig with the appropriate flags set. Start again with
Flowchart 4. - F.
Command hangs? If a message
is not returned after executing ping, go to Flowchart 5. - G.
Unknown host? (Error= Unknown
host hostname?) There is a problem with the configuration for the
host in the /etc/hosts file or on the name server. - H.
Correct BIND, NIS or /etc/hosts configuration. Add
the missing host name and start again with Flowchart 4. - I.
No route to host? (Error= Sendto:
No route to host?) Use netstat -rn to check the routing table. If there is no route
table entry for the host, go to J. Otherwise, call your HP representative
for help. Be prepared to discuss the problem as described in "Contacting
Your HP Representative" at the end of this chapter. - J.
Add route table entry. Using route, add a route table entry for that host.
Flowchart 5: Network Level Loopback Test continued | |
- 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, suppose the remote host
is known as 192.6.20.2. Enter: arp 192.6.20.2 - 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 likely is why there is no entry in the ARP cache. - C.
LAN card O.K.? Use lanadmin to ensure the remote LAN card is operational. - D.
Replace or reset LAN card. When
the LAN card is operational, use lanadmin (1M) to reset. Refer to the lanadmin(1M) command description or sample output in this chapter. - E.
Bring-up remote host. Have
the node manager of the remote host bring that system up. - F.
Entry complete? Perhaps there
is an ARP cache entry, but it is wrong or not complete. - G.
Use arp to complete entry. Using arp, enter the correct Station Address. For more information,
refer to the arp(1M) man page. - H.
ping local host. Using ping, do an internal loopback on your own system. In
other words, ping your own IP address. This will find if the problem
is on your end. - I.
ping successful? 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. If this is true,
the network interface or software on the remote host is suspect.
Start again with Flowchart 4, but this time ping from the remote host to your system. If the ping was not successful, call your HP representative
for help.
Flowchart 6: Transport Level Loopback Test (using Internet
Services) | |
- 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
okay through the Transport Layer (OSI Layer 4). - C.
Execute: ftp to remote host. Unlike telnet, ftp does not go through a pseudo-terminal 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 configured on local or 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.
Configure TCP. If necessary,
install TCP on either or both hosts. - G.
Network congested? If TCP is
installed on both hosts, do a file transfer to another remote host
on the network. Use netstat to check for lost packets. If 10 percent or more packets are lost, the network is extremely
busy. If you cannot determine the cause, contact your HP representative
for help. If both ftp and telnet fail, the /etc/inetd.conf file may be configured incorrectly or the inetd daemon may not be running on the remote system. If the problem is not resolved, more detailed diagnostics
are required. Again, contact your HP representative.
Flowchart 7: Link Level Loopback Test | |
- A.
Execute: linkloop on local interface. Execute
the linkloop command with the station address of the local
interface. Execute lanscan (1M) to find the link level address (station address)
on the remote host or obtain it from your network map. For more
information on linkloop, refer to the man page. - B.
linkloop successful? If not,
your LAN card may not be operational. Go to Flowchart 8. - C.
Execute: linkloop to remote host. Enter
the link level address (station address) of the remote host. - D.
linkloop successful? If the
test was successful, stop. Network connectivity is okay through
the Link Layer (OSI Layer 2). If not successful, note which error
was returned and continue with this flowchart. - E.
Loopback failed; Address has bad format. The
link level address is not correct. Go to F. - F.
Loopback failed; Not an individual address. The
link level address is not correct. The second hexadecimal digit
is odd. This means it is a multicast or broadcast address, which
is not allowed. The address must be unique to one remote host. Go
to H. - G.
Loopback failed. The remote
host did not respond. Go to I. - H.
Correct the link address parameter. Change
the link level address to an allowed value and go to C. - I.
Choose a different IEEE 802.3 host; re-execute
linkloop. Restart this flowchart using a different remote
host. NOTE: Make sure the remote host is an HP 9000 Systems and
try again. - J.
linkloop successful? If the
test was successful, stop. Network connectivity is okay through
the Link Layer (OSI Layer 2). If not successful, go to K. - K.
Check remote host's connectivity to LAN. 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
Flowcharts 1 and 12 to verify configuration and connectivity of
the remote host.
Flowchart 8: LAN Connections Test | |
- A.
Thick or thin cabling? If your
network cabling is the thicker coaxial cabling, continue in the
direction marked "Thick Coax." If your network
cabling is the ThinLAN cabling, continue in the direction marked "ThinLAN." - A1.
RJ45 Adapter? Verify LEDs.
Network Activity and Link Status LED displays: Link Status LED is
lit GREEN for a valid link. Network Activity LED is lit AMBER color
for both 10 Mbps and 100Mbps. Sometime Link Status LED is not lit
up at 10 Mbps mode. - A2.
Card seated securedly? Check
adapter installation, reset and reseat adapter. Check for incorrect
or faulty network cable or connector. Ensure settings for switch and
adapter are the same. - B.
Check: AUI solidly connected to LAN card. Make
sure the AUI cable is solidly connected to the LAN card. If the
AUI cable is not connected, turn off the power to the computer before
you connect it. - C.
Check: ThinLAN cable terminated at both
ends. Make sure the backbone cable is terminated at both
ends. - D.
Check: BNC T-connectors secure. Make
sure each BNC T-connector is securely attached to a BNC connector
on the ThinLAN cable and that no intervening cable is between the
MAU and the T-connector. - E.
Check: ThinLAN cable grounded in only
one place. Make sure the ThinLAN cable is grounded in
only one place. - F.
Problem solved? If so, stop.
If you still have a problem after working through this flowchart,
you may have a failed LAN card, an incorrect jumper setting on the LAN
card, or a problem with the transmit or receive function of the
MAU. Contact your HP representative for help. Be prepared to discuss
the problem as described in "Contacting Your HP Representative" at the
end of this chapter. - G.
Check: AUI solidly connected to MAU and
LAN card. Make sure the AUI cable is solidly connected
to the MAU and the LAN card. If the AUI cable is not connected,
turn off the power to the computer before you connect it. - H.
Check: Backbone cable terminated at both
ends. Make sure the backbone cable is terminated at both
ends. - I.
Check: MAU tapped securely into cable. Make
sure the MAU is tapped securely into the backbone cable. - J.
Check: Splices and Taps. Make
sure all splices and taps are secure. - K.
Check: Backbone cable grounded in only
one place. Make sure the backbone cable is grounded in
only one place.
Flowchart 9: Gateway Remote Loopback Test | |
- A.
Execute: ping from known good host through
gateway to known good host on remote network. This will
test gateway connectivity to the remote network. For more information
on ping(1M), refer to chapter 6. - B.
ping successful? If the executing ping returned successfully, the problem may exist in
the routing table for the problem host. Go to C. - C.
Execute netstat -rn. To display
gateway routing information in numerical form, execute: netstat -rn - D.
Direct route to remote or default route
to gateway? If the route exists, go to F. If not, go
to E to add a new route. - E.
Add route entry on local system. Use
the route(1M) command to add a route entry to the route table
on the local system. Refer to route(1M) for a complete description of the command. - F.
Routing table on remote OK? Check
that the routing information on the remote system is OK. - G.
Correct routing table. If the
routing information is incorrect, correct it using the route(1M) command.
Flowchart 10: Gateway Remote Loopback Test continued | |
- A.
Examine gateway. If the gateway
is an HP 9000, go to C. If it is not, go to B. - B.
Other HP; other vendors. Go
to C. - C.
Refer to networking documentation. Refer
to the documentation that came with the gateway for additional diagnostics. - D.
HP 9000. Go to E. - E.
Execute: ifconfig on gateway host. Execute ifconfig for all network interfaces on the gateway. - F.
Network interface up? If the
output from ifconfig does not include the UP parameter, the network
interface is down. Execute netstat -in to check the status of the network interfaces.
An asterisk (*) next to the interface indicates that the interface
is down. If the network interface is down, go to Flowchart 2. If the
network interfaces are UP, start again with Flowchart 1. Using Flowchart
1, test all network interfaces on the gateway. Use netstat -in to make sure that the configured encapsulation
is correct.
| | | | | NOTE: Running is always displayed. It indicates only that
there is OS support for the interface. | | | | |
- G.
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.
Flowchart 11: Subnet Test | |
- A.
Host Portion all 0's or all 1's? Execute ifconfig(1M). Is the host portion of the IP address all 0's
or all 1's? These values are reserved. Refer to chapter 6 for details
on subnets. If the host portion of the IP address is all 0's or
all 1's, go to B to correct the IP address. Otherwise, go to C to
examine the subnetwork number. - B.
Correct IP address. Correct
the IP address and start again with Flowchart 11. - D.
Subnet mask set to what you expect? Check
your network map and execute ifconfig(1M) to determine the subnet mask for your node. Refer
to chapter 6 for details on subnets. If the subnet mask is not what
you expect, go to I. Otherwise, go to E. - E.
All hosts on subnet using same subnet
mask? Execute ifconfig(1M) for every network interface on each node on the
entire network. If all nodes are using the same subnet mask, go
to F. Otherwise, go to J to correct the subnet masks. - F.
All hosts on network have subnet mask
set? Execute ifconfig for every network interface on each node on the
entire network. If all nodes have the same subnet mask set, go to
G. Otherwise, go to K to set the correct subnet masks. - G.
Check route table on source, destination. Execute netstat -rv on the two hosts. Go to H. - H.
Correct the route tables (if necessary). In
general, specify a network, not a host when adding to the route table.
Specifying a network as the destination enables you to add nodes
to the remote destination subnetwork without updating the route
tables on the local subnetwork every time you add a node to the
remote subnetwork. - I.
Correct IP address. Set the
subnet mask to the proper value. Go to D. - J.
Correct subnet mask. To do
so, execute ifconfig with the proper subnet mask. Go to D. - K.
Correct subnet mask. To do
so, execute ifconfig with the proper subnet mask. Go to D.
|
Printable version
