tyt13fi.htm

一个学习tcp/ip协议的教程

wrcache    write      create     remove     rename     link       symlink

0 0%       0 0%       0 0%       0 0%       0 0%       0 0%       0 0%

mkdir      rmdir      readdir    fsstat

0 0%       0 0%       239 19%    98 8%</FONT></PRE><P>The mount program shows which directories are currently mounted, and the command showmount shows the current NFS servers on the system:<BR><PRE>

<FONT COLOR=#000080>$ mount

pepper:/               /server               nfs ro,bg,intr

pepper:/apps           /server/apps          nfs ro,bg,intr

pepper:/usr            /server/usr           nfs rw,bg,intr

pepper:/u1             /server/u1            nfs rw,bg,intr

$ showmount

m_server.tpci.com

merlin.tpci.com

sco_gate.tpci.com

tpti.tpci.com</FONT></PRE><P>The mount output shows the directories on the machine named pepper that were mounted onto the local /server directory when the system booted. The permissions for each mounted directory are shown at the end of each line, where ro means read-only and rw means read-write<I>. </I>The bg in the status lines means background<I>, </I>indicating that if the mount fails, the system tries again periodically. The intr option means that keyboard interrupts can be used to halt the reconnection attempts.<BR><P>Also available as public domain software are nfswatch and nhfsstone. The nfswatch utility monitors all NFS traffic on a server and updates status information at predetermined intervals. This can be useful for watching the load change during the day. The nhfsstone utility is for benchmarking, generating an artificial load and measuring the results.<BR><P>A fast method to verify a port's proper functioning is to connect to it with Telnet or FTP. Both programs enable the user to specify the port to use instead of the default. In the following example, port 25 (usually used for mail) is tested:<BR><PRE>

<FONT COLOR=#000080>$ telnet tpci_hpws4 25

Trying 127.12.12.126 ...

Connected to tpci_hpws4.

Escape shcracter is '^]'.

220 tpci_hpws4 Sendmail 3.1 ready at Sat, 2 July 94 12:16:54 EST

HELO TPCI_SERVER_1

250 tpci_hpws4 This is garbage typed to force a closed connections as it doesn't understand this stuff

QUIT

221 tpci_hpws4 closing connection

Connection closed by foreign host.</FONT></PRE><P>In this example, port 25 received the connection request properly and waited for the mail protocol messages. Because it didn't get any, it closed the connection. This short session establishes that port 25 is functioning properly as far as connections are concerned. It doesn't convey any information about the integrity of the mail transfer protocol, though.<BR><P>All of these utilities can be combined to provide a troubleshooting checklist for basic problems. These tell you at least where the problem is, if not more. A diagnostic procedure is assembled from the utilities, such as the following:<BR><UL><LI>If DNS is on the system, use a DNS utility such as nslookup to ensure that DNS is active.<BR></LI><BR><LI>If NFS is used, check it with the mount utility.<BR></LI><BR><LI>Use ping to check whether a remote machine is alive.<BR></LI><BR><LI>Use traceroute to ensure that a routing problem is not occurring. Check all ports of the routers if traceroute fails (use the Telnet login process shown previously).<BR></LI><BR><LI>Use netstat to examine ICMP messages recently generated.<BR></LI><BR><LI>Try logging into the remote directly with FTP or Telnet.<BR></LI><BR><LI>If RPCs appear to be the problem, use rpcinfo.<BR></LI><BR></UL><P>Of course, if better tools are available from commercial sources, use them to their full advantage. It is important to know that you don't have to spend thousands of dollars on a network monitoring tool, because the utilities supplied with the operating system are often quite capable (if not as fancy or graphically oriented).<BR><BR><A ID=E69E174 NAME=E69E174></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Troubleshooting the Network Interface</B></FONT></CENTER></H4><BR><P>The physical connection to the network is a suitable starting point for troubleshooting when a problem is not obvious. Because there are many popular network interfaces, each of which must be dealt with in a slightly different manner, some generalizations must be made. The overall approach remains the same, however.<BR><P>Assuming that the network itself is functional, the most common problems with the network interface are a faulty network card or a bad connector. Checking each is easily done by simple replacement. If the problem persists, the fault is most likely higher in the architecture.<BR><P>Faulty network transport media (usually cables) are not uncommon. If a device at the end of a cable is not functioning, it is worthwhile to check the cable itself to ensure that a communication path exists. This can be done with a portable computer or terminal, or in some cases a conductivity tester, depending on the network. A systematic testing process can narrow down a network cabling problem to a specific segment.<BR><P>One overlooked problem arises not because of a real fault with the network interface or the network itself, but because one device on the network is transmitting a different protocol. This can foul up the entire network and grind it to a halt. (For example, an Ethernet network might have one or more devices set to transmit IEEE 802.3 frames, which are not the same as Ethernet.)<BR><P>If there is a conversion from one protocol to another, that can be suspect. For example, it is common to find AppleTalk networks running TCP/IP. The IP messages are encapsulated in AppleTalk frames. If the conversion between the two formats (which can occur at a gateway or router) is not clean, some faulty packets might be passed. This can cause network problems.<BR><P>If the network connections and network interface cards appear to be working (which can be verified with a network analyzer or board swapping), the problem is in a higher layer.<BR><BR><A ID=E69E175 NAME=E69E175></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Troubleshooting the Network (IP) Layer</B></FONT></CENTER></H4><BR><P>The network layer (where IP resides) can be the most trouble-prone aspect of the network if configuration rules are not followed scrupulously. Because this layer handles routing, any mistakes can cause lost packets, making it appear that a machine on the network is not communicating with the others. ICMP can be a useful tool for troubleshooting this layer.<BR><P>One of the most common mistakes, especially with large networks, is a duplication of IP addresses. This can be an accident, as a new address is programmed, or a user can move his or her machine and in the process jumble the IP address. It is not uncommon for users to change the IP address by mistake when investigating the software. The network mask must also be correct.<BR><P>Addressing of packets within the IP layer (where the source and destination IP addresses are encapsulated in the IP header) is another source of problems. Determining destination IP addresses requires communications with another machine, which should hold the necessary information. If the Domain Name System (DNS) is active, it can contribute to the confusion if the server has faulty tables.<BR><P>It is necessary for the IP address to be mapped to the physical address. Both ARP and RARP require this table to direct packets over the network. If a network card is changed for any reason, the unique physical address on the board no longer corresponds to the IP address, so messages are rerouted elsewhere. Network administrators must keep close track of any changes to the network hardware in all devices.<BR><P>Problems can also occur with devices that handle intermediary routing, such as bridges, routers, and brouters. These must be aware of all changes to the network, as well as physical and logical addresses for the devices they are connected to. Specialized protocols such as Routing Information Protocol (RIP) and Open Shortest Path First (OSPF) handle much of this maintenance, but somewhere in the network a manual notation of changes must be made.<BR><P>There are many potential sources of trouble with the network layer. Even processes that should work without trouble, such as packet fragmentation and reassembly, can cause problems.<BR><P>Connectivity between machines at both the transport and network level can be tested using utilities such as ping. A systematic check of machines along a network and out over an internetwork can help isolate problems, not just in the source and destination machines but also in intermediate processors such as routers. The traceroute utility can be used for this, also, if it is available.<BR><BR><A ID=E69E176 NAME=E69E176></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Troubleshooting TCP and UDP</B></FONT></CENTER></H4><BR><P>Assuming the network layer is functioning correctly, the host-to-host software might be a problem. If the software is correctly installed and started (which might sound obvious but is a common cause of failure), a process to isolate the problem must be followed. There are many files involved with both TCP and UDP, differing with each operating system version, so the documentation accompanying the TCP or UDP software should be consulted.<BR><P>The protocol in use must be determined first: Is the machine using TCP or UDP, and if both, are both failing? Problems such as too many retransmissions or no timeout values can make UDP appear as if it is failing, but TCP would not be affected (unless it uses the same port or too many processes are active).<BR><P>Port addresses can be problematic, especially with TCP. Each port on a machine can be sent a ping message from a remote machine to verify that it is communicating properly. If a port request fails, it might indicate an improper or missing entry in a configuration file. The finger utility might also be useful. If messages are passing correctly from one machine to another, the problem is in the configuration of the software, or a higher level application.<BR><P>Incorrect configuration parameters can cause TCP or UDP failures. For example, if the send and receive window values for TCP are set to low levels, there might be no opportunity for applications to pass enough information. In this case, it might appear that TCP is at fault. Carefully check all configuration files and settings.<BR><BR><A ID=E69E177 NAME=E69E177></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Troubleshooting the Application Layer</B></FONT></CENTER></H4><BR><P>Assuming that both IP and TCP or UDP are functioning properly, the application layer is suspect. It is in this layer that higher-level protocols such as the File Transfer Protocol (FTP), Telnet, and SMTP are based. It can be difficult to find problems within the application layer, although a few simple tests help eliminate obvious solutions. Several commercial utilities are available to monitor reception within the application layer.<BR><P>Assuming that data is getting to the right application (which can be checked with some diagnostic tools or simple programming routines), the problem might be in interpretation. Verify that the communications between two applications are both the same format. More than one application has expected ASCII and received EBCDIC. Diagnostics show the messages moving into the application properly, but they are total gibberish to the application when it tries to interpret them.<BR><P>Assuming that is not the problem, there could be a fault with the applications at either end. Although you might assume that a Telnet program from one vendor would talk to one from another vendor, this is not true in an unfortunately large number of cases. If there are no identical software packages or versions known to work with the other package, this can be difficult to troubleshoot. This kind of cross-application problem is particularly prevalent with mixed-platform systems, such as a PC-based FTP or TCP/IP software package trying to access services on a UNIX host.<BR><P>Some readily available utilities can be used to monitor the application layer. Some of these utilities are distributed with operating systems, and others are distributed as public domain software. The utility snmpwatch is a network monitoring program that reports on any SNMP variables that change their values. This can be helpful in diagnosing communications problems within SNMP.<BR><P>The Internet Rover is a network monitoring program that enables testing of several protocols, including Telnet, FTP, and SMTP. Unfortunately, it doesn't work with all operating system variants. Another tool for SMTP testing is mconnect, which verifies connections.<BR><BR><A ID=E68E122 NAME=E68E122></A><H3 ALIGN=CENTER><CENTER><FONT SIZE=5 COLOR=#FF0000><B>Security</B></FONT></CENTER></H3><BR><P>This is not the place for a long discourse on computer security. Instead, I touch on the impact security has on TCP/IP-based networks only in the slightest terms. Security is an important issue and one often overlooked, usually to the administrator's rue. Taking the steps to set up a proper security policy and protecting the system as well as possible should be a mandatory task for every system administrator.<BR><P>Routers can be significant in a network's security plan. Most routers enable the system administrator to restrict traffic through the router in some manner, either in one direction or both. A router can be set, for example, to prohibit Telnet or rlogin requests from outside the network, but enable through file transfer requests such as FTP. Routers can also prevent traffic into a local network through the router from anywhere outside the network, cutting down on access into (and through) a network.<BR><P>Routers usually perform this type of traffic filtering by simply looking at the datagram headers for the requested port. If one of the restricted ports is requested, the datagram can be returned to the sender or discarded. Setting the proper access filters from a network router can be an effective and simple manner of restricting outside access.<BR><P>Unfortunately, the Internet and most networks were simply not designed to prevent unauthorized access or monitoring. These features were usually added as an afterthought, and as such have some problems. Watching network traffic and trapping addresses, user IDs, and passwords is ridiculously easy, so MIT developed Kerberos security protocols to help.<BR><P>Kerberos (named after the three-headed dog guarding the gates of Hades) uses an encryption key and server introduction method to enable access. Kerberos is slowly being adopted as a standard among Internet users (despite some governmental protests), and it works well with the TCP/IP family of protocols. For more information on Kerberos, connect to ATHENA.MIT.EDU over the Internet or send e-mail to that site requesting information.<BR><BR><A ID=E68E123 NAME=E68E123></A><H3 ALIGN=CENTER><CENTER><FONT SIZE=5 COLOR=#FF0000><B>Summary</B></FONT></CENTER></H3><BR><P>I took a brief look at the network management and troubleshooting tools available with TCP/IP. As mentioned in the introduction, both subjects are complex, potentially demanding, and still considered by many to be an art. There are many excellent books on network management, so you are encouraged to scour your library or bookstore for ones that interest you if you want to know more about this subject.<BR><P>The tools provided within the TCP/IP family give you enough diagnostic resources to isolate the source of practically any software or hardware problem. Sometimes the solution to a problem is simple and can be easily managed through a configuration change. Often, though, a problem is outside the bounds of TCP/IP's protocol, requiring more powerful diagnostic procedures. It is useful to follow the steps outlined in this chapter first, and resort to other systems only when the TCP/IP diagnostics have been unable to help.<BR><P>System administration and network troubleshooting are both curious tasks. They require a lot of work at times, but there is an undeniable sense of accomplishment when a network runs smoothly or you have tracked down and fixed a problem. Although only a few users in every group are called upon to perform either task, those that do are in for quite an adventure!<BR><BR><A ID=E68E124 NA