TCP/IP administration involves the procedures that you use to configure your network. First you assemble the hardware. Then you configure TCP/IP. This chapter explains how to configure TCP/IP. This chapter also addresses how to troubleshoot TCP/IP problems.
This chapter contains the following information:
Before you configure TCP/IP, complete the tasks that are listed in the following table.
Table 4–1 Before You Configure TCP/IP Task Map
Description |
For Instructions, Go To ... |
---|---|
Design the network topology. |
See Network Topology. |
Obtain a network number from your Internet addressing authority. | |
Assemble the network hardware depending on the network topology. Assure that the hardware is functioning properly. |
See the hardware manuals and Network Topology. |
Run configuration software that is required by network interfaces and routers, if applicable. |
See Adding Routers and Configuring Routers for information on routers. |
Plan the IP addressing scheme for the network. If applicable, include subnet addressing. |
See Designing Your IPv4 Addressing Scheme and IPv6 Addressing. |
Assign IP numbers and host names to all machines in the network. |
See Designing Your IPv4 Addressing Scheme and IPv6 Addressing. |
Determine which name service your network uses: NIS, NIS+, DNS, or local files. |
See System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) and System Administration Guide: Naming and Directory Services (FNS and NIS+). |
Select domain names for your network, if applicable. |
See System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) and System Administration Guide: Naming and Directory Services (FNS and NIS+). |
Install the operating system on at least one machine on the network. |
As a network administrator, you configure TCP/IP to run on hosts and routers (if applicable). You can configure these machines to obtain configuration information from files on the local machine or from files that are located on other machines on the network. You need the following configuration information:
Host name of a machine
IP address of the machine
Domain name to which the machine belongs
Default router
Netmask in use on the machine's network (if applicable)
A machine that obtains TCP/IP configuration information from local files operates in local files mode. A machine that obtains TCP/IP configuration information from a remote machine operates in network client mode.
To run in local files mode, a machine must have local copies of the TCP/IP configuration files. TCP/IP Configuration Files describes the files. The machine should have its own disk, though this recommendation is not strictly necessary.
Most servers should run in local file mode. This requirement includes the following servers:
Network configuration servers
NFS servers
Name servers that supply NIS, NIS+, or DNS services
Mail servers
Additionally, routers should run in local files mode.
Machines that exclusively function as print servers do not need to run in local files mode. Whether individual hosts should run in local files mode depends on the size of your network.
If you are running a very small network, the amount of work that is involved in maintaining these files on individual hosts is manageable. If your network serves hundreds of hosts, the task becomes difficult, even with the network divided into a number of administrative subdomains. Thus, for large networks, using local files mode is usually less efficient. However, because routers and servers must be self-sufficient, they should be configured in local files mode.
Network configuration servers are the machines that supply the TCP/IP configuration information to hosts that are configured in network client mode. These servers support three booting protocols:
RARP – Reverse Address Resolution Protocol (RARP) maps Ethernet addresses (48 bits) to IPv4 addresses (32 bits), the reverse of ARP. When you run RARP on a network configuration server, hosts that are running in network client mode obtain their IP addresses and TCP/IP configuration files from the server. The in.rarpd daemon enables RARP services. Refer to the in.rarpd(1M) man page for details.
TFTP – Trivial File Transfer Protocol (TFTP) is an application that transfers files between remote machines. The in.tftpd daemon executes TFTP services, enabling file transfer between network configuration servers and their network clients. Refer to the in.tftpd(1M) man page for details.
bootparams – The bootparams protocol supplies parameters for booting that are required by clients that boot off the network. The rpc.bootparamd daemon executes these services. Refer to the bootparamd(1M) man page for details.
Network configuration servers can also function as NFS file servers.
If you are configuring any hosts as network clients, then you must also configure at least one machine on your network as a network configuration server. If your network is subnetted, then you must have at least one network configuration server for each subnet with network clients.
Any host that obtains its configuration information from a network configuration server operates in network client mode. Machines that are configured as network clients do not require local copies of the TCP/IP configuration files.
Network client mode simplifies administration of large networks. Network client mode minimizes the number of configuration tasks that you perform on individual hosts. Network client mode assures that all machines on the network adhere to the same configuration standards.
You can configure network client mode on all types of computers. For example, you can configure network client mode on fully standalone systems or dataless machines.
Configurations are not limited to either an all-local-hosts mode or an all-network-client mode. Routers and servers should always be configured in local mode. For hosts, you can use any combination of local and network client mode.
The following figure shows the hosts of a fictitious network with the network number 192.9.200. The network has one network configuration server, the machine sahara. Machines tenere and nubian have their own disks and run in local files mode. Machine faiyum also has a disk, but this machine operates in network client mode.
Finally, the machine timbuktu is configured as a router. The machine includes two network interfaces. The first interface is named timbuktu. This interface belongs to network 192.9.200. The second interface is named timbuktu-201. This interface belongs to network 192.9.201. Both networks are in the organizational domain deserts.worldwide.com. The domain uses local files as its name service.
Most examples in this chapter use the network that is shown in the following figure.
If you are changing from a network that does not use a subnet to one that does use a subnet, perform the the tasks in the following table.
Table 4–2 Adding a Subnet to a Network Task Map
Description |
For Instructions, Go To ... |
---|---|
1. Decide on the new subnet topology, including considerations for routers and locations of hosts on the subnets. | |
2. Assign all subnet and host addresses. |
Setting Up an IP Address Scheme and Parts of the IPv4 Address. |
3. Modify the /etc/inet/netmasks file, if you are manually configuring TCP/IP, or supply the netmask to the Solaris installation program. |
netmasks Database and Creating the Network Mask for IPv4 Addresses. |
4. Modify the /etc/inet/hosts and /etc/inet/ipnodes files on all hosts to reflect the new host addresses. | |
5. Reboot all machines. |
Network software installation occurs along with the installation of the operating system software. At that time, certain IP configuration parameters must be stored in appropriate files so they can be read at boot time.
The procedure is a matter of creating or editing the network configuration files. How configuration information is made available to a machine's kernel is conditional. The availability depends on whether these files are stored locally (local files mode) or acquired from the network configuration server (network client mode).
The parameters that are supplied during network configuration follow:
IP address of each network interface on every machine.
Host names of each machine on the network. You can type the host name in a local file or a name service database.
NIS, NIS+, or DNS domain name in which the machine resides, if applicable.
Default router addresses. You supply this information if you have a simple network topology with only one router attached to each network. You also supply this information if your routers do not run routing protocols such as the Router Discovery Server Protocol (RDISC) or the Router Information Protocol (RIP). See Routing Protocols for more information about these protocols.
Subnet mask (required only for networks with subnets).
This chapter contains information on creating and editing local configuration files. See System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) and System Administration Guide: Naming and Directory Services (FNS and NIS+) for information on working with name service databases.
Task |
Description |
For Instructions, Go To ... |
---|---|---|
Configure a host for local files mode |
Involves editing the nodename, hostname, hosts, defaultdomain, defaultrouter, and netmasks files | |
Set up a network configuration server |
Involves turning on the in.tftp daemon, and editing the inetd.conf, hosts, ethers, and bootparams files | |
Configure a host for network client mode |
Involves creating the hostname file, editing the hosts file, and deleting the nodename and defaultdomain files, if they exist | |
Specify a router for the network client |
Involves editing the defaultrouter and hosts files |
Use this procedure for configuring TCP/IP on a machine that runs in local files mode.
Become superuser and change directories to /etc.
Type the host name of the machine in the file /etc/nodename.
For example, if the name of the host is tenere, type tenere in the file.
Create a file that is named /etc/hostname.interface for each network interface.
The Solaris installation program automatically creates this file for the primary network interface. Refer to /etc/hostname.interface File for details. If you are using IPv6, see IPv6 Network Interface Configuration File.
Type either the interface IP address or the interface name in each /etc/hostname.interface file.
For example, create a file that is named hostname.ie1, and type either the IP address of the host's interface or the host's name.
Edit the /etc/inet/hosts file to add the following:
IP addresses that you have assigned to any additional network interfaces in the local machine, along with the corresponding host name for each interface.
The Solaris installation program has already created entries for the primary network interface and loopback address.
IP address or addresses of the file server, if the /usr file system is NFS mounted.
The Solaris installation program creates the default /etc/inet/hosts for the local machine. If the file does not exist, create the file as shown in hosts Database. Also, if you are using IPv6, see /etc/inet/ipnodes File.
Type the host's fully qualified domain name in the /etc/defaultdomain file.
For example, suppose host tenere was part of the domain deserts.worldwide.com. Therefore, you would type deserts.worldwide.com in /etc/defaultdomain. See /etc/defaultdomain File for more information.
Type the router's name in /etc/defaultrouter.
See /etc/defaultrouter File for information about this file.
Type the name of the default router and its IP addresses in /etc/inet/hosts.
Additional routing options are available. Refer to the discussion on routing options in How to Configure Hosts for Network Client Mode. You can apply these options to a local files mode configuration.
If your network is subnetted, type the network number and the netmask in the file /etc/inet/netmasks.
If you have set up an NIS or NIS+ server, you can type netmask information in the appropriate database on the server if server and clients are on the same network.
Become superuser and change to the root directory of the prospective network configuration server.
Turn on the in.tftpd daemon by creating the directory /tftpboot:
# mkdir /tftpboot |
This command configures the machine as a TFTP, bootparams, and RARP server.
Create a symbolic link to the directory.
# ln -s /tftpboot/. /tftpboot/tftpboot |
Enable the tftp line in inetd.conf.
Check that the /etc/inetd.conf entry reads as follows:
tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot |
This line prevents inettftpd() from retrieving any file other than the file that is located in /tftpboot.
Edit the hosts database, and add the host names and IP addresses for every client on the network.
Edit the ethers database, and create entries for every host on the network to run in network client mode.
Edit the bootparams database.
See bootparams Database. Use the wildcard entry or create an entry for every host that runs in network client mode.
On a command line, type the following command.
# pkill -HUP inetd |
Information for setting up install servers and boot servers is found in Solaris 9 Installation Guide.
Network clients receive their configuration information from network configuration servers. Therefore, before you configure a host as a network client you must ensure that at least one network configuration server is set up for the network.
Do the following on each host to be configured in network client mode:
Become superuser.
Check the directory for the existence of an /etc/nodename file. If such a file exists, delete it.
Eliminating /etc/nodename causes the system to use the hostconfig program to obtain the host name, domain name, and router addresses from the network configuration server. See Network Configuration Procedures.
Create the file /etc/hostname.interface, if this file does not exist.
Ensure that the file is empty. An empty /etc/hostname.interface file causes the system to acquire the IP address from the network configuration server. If you are using IPv6, see IPv6 Network Interface Configuration File.
Ensure that the /etc/inet/hosts file contains only the host name and IP address of the loopback network interface.
For more information, see Loopback Address. The file should not contain the IP address and host name for the local machine (primary network interface). If you are using IPv6, see /etc/inet/ipnodes File.
Check for the existence of an /etc/defaultdomain file. If such a file exists, delete it.
The hostconfig program sets the domain name automatically. If you are overriding the domain name that is set by hostconfig, type the substitute domain name in the file /etc/defaultdomain.
Ensure that the search paths in the client's /etc/nsswitch.conf reflect the name service requirements for your network.
If only one router is on the network and the network configuration server is to specify its name automatically, ensure that no /etc/defaultrouter file exists on the network client.
To override the name of the default router that is provided by the network configuration server, do the following:
If you have multiple routers on the network, create /etc/defaultrouter on the network client, but leave this file empty.
Creating /etc/defaultrouter and leaving this file empty causes one of the two dynamic routing protocols to run: ICMP Router Discovery Protocol (RDISC), or Routing Information Protocol (RIP). The system first runs the program in.rdisc, which looks for routers that are running the router discovery protocol. If in.rdisc finds one such router, in.rdisc continues to run and monitors the routers that are running the RDISC protocol.
If the system discovers that routers are not responding to the RDISC protocol, the system uses RIP and runs the in.routed daemon to monitor the routers.
Services such as telnet, ftp, and rlogin are started by the inetd daemon, which runs automatically at boot time. Refer to the inetd(1M) and inetd.conf(4) man pages.
In addition to the service definitions in the /etc/inetd.conf file, you can configure inetd by using the /etc/default/inetd file. For example, you can configure the logging of all incoming connections. You can also configure the use of the TCP Wrappers facility for access control.
Become superuser.
Turn logging on by editing the /etc/default/inetd file by adding the following line:
ENABLE_CONNECTION_LOGGING=YES |
If the previous line already exists with a comment symbol, then you can just delete the comment symbol.
Kill the inetd daemon.
Restart the inetd daemon.
See System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) and System Administration Guide: Naming and Directory Services (FNS and NIS+) for further information on name services.
Become superuser.
Turn TCP Wrappers on by editing the /etc/default/inetd file by adding the following line.
ENABLE_TCPWRAPPERS=YES |
If the previous line already exists with a comment symbol, then you can just delete the comment symbol.
Kill the inetd daemon.
Restart the inetd daemon.
Configure the TCP Wrappers access control policy as described in the hosts_access(4) man page.
TCP/IP's first requirement for a router is that the machine must have at least two network interfaces installed. If one of the network interfaces is not disabled, the router automatically “talks” to the RDISC and RIP protocols. These protocols monitor routers on the network and advertise the router to the hosts on the network.
After the router is physically installed on the network, configure the router to operate in local files mode, as described in How to Configure a Host for Local Files Mode. This configuration ensures that routers boot if the network configuration server is down. Remember that, unlike a host, a router has a minimum of two interfaces to configure.
Task |
Description |
For Instructions, Go To ... |
---|---|---|
Configure a machine as a router |
Involves creating hostname and hosts file and adding addresses | |
Select static routing on a host that is a network client |
Involves adding an entry into the defaultrouter file |
How to Select Static Routing on a Host That Is a Network Client |
Select dynamic routing on a host that is a network client |
Involves editing entries in the defaultrouter file |
How to Select Dynamic Routing on a Host That Is a Network Client |
Force a machine to be a router |
Involves creating a gateways file |
Because a router provides the interface between two or more networks, you must assign a unique name and IP address to each of the router's network interface cards. Thus, each router has a host name and an IP address that are associated with its primary network interface, plus a minimum of one more unique name and an IP address for each additional network interface.
Become superuser on the machine to be configured as a router.
Create an /etc/hostname.interface file for each network interface that is installed.
For example, create hostname.ie0 and hostname.ie1. See /etc/hostname.interface File for more information. If you are using IPv6, see IPv6 Network Interface Configuration File.
In each file, type the host name you have selected for that interface.
For example, you could type the name timbuktu in the file hostname.ie0, then type the name timbuktu-201 in the file hostname.ie1. Both interfaces would be located on the same machine.
Type the host name and IP address of each interface into /etc/inet/hosts.
For example:
192.9.200.20 timbuktu #interface for network 192.9.200 192.9.201.20 timbuktu-201 #interface for network 192.9.201 192.9.200.9 gobi 192.9.200.10 mojave 192.9.200.110 saltlake 192.9.200.12 chilean |
The interfaces timbuktu and timbuktu-201 are on the same machine. Notice that the network address for timbuktu-201 is different from that of timbuktu. The difference exists because the medium for network 192.9.201 is connected to the timbuktu-201 network interface while the media for network 192.9.200 is connected to the timbuktu interface. If you are using IPv6, see /etc/inet/ipnodes File.
If the router is connected to any subnetted network, edit /etc/inet/netmasks and type the local network number (129.9.0.0, for example) and associated netmask number (255.255.255.0, for example).
The startup script determines whether to start up a routing protocol (RIP or RDISC) on the machine or use static routing.
Become superuser on the host.
Add an entry for a router on the network into the /etc/defaultrouter file.
See /etc/defaultrouter File. A single static default route is then installed in the routing table. Under this condition, the host does not run any dynamic routing protocol (such as RIP and RDISC).
Become superuser on the host.
Ensure that the /etc/defaultrouter file is empty.
If this file is empty, a network client is forced to select a dynamic routing protocol.
The type of dynamic routing used is selected by using the following criteria:
If the /usr/sbin/in.rdisc program exists, the startup script starts in.rdisc. Any router on the network that is running RDISC then responds to any RDISC queries from the host. If at least one router responds, the host selects RDISC as its routing protocol.
If the network router is not running RDISC or fails to respond to the RDISC queries, then in.rdisc on the host exits. The host then starts in.routed, which runs RIP.
You can force a machine that has only one /etc/hostname.interface file (by default a host) to be a router.
Become superuser on the machine.
Create a file that is named /etc/gateways and leave this file empty.
This procedure is important if you decide to configure PPP links, as explained in System Administration Guide: Resource Management and Network Services.
By default, TCP/IP considers any machine with multiple network interfaces to be a router. However, you can change a router into a multihomed host—a machine with more than one network interface that does not run routing protocols or forward IP packets. You typically configure the following types of machines as multihomed hosts:
NFS servers, particularly large data centers, can be attached to more than one network in order to share files among a large pool of users. These servers do not need to maintain routing tables.
Database servers can have multiple network interfaces for the same reason as NFS servers—to provide resources to a large pool of users.
Firewall gateways are machines that provide the connection between a company's network and public networks such as the Internet. Administrators set up firewalls as a security measure. When configured as a firewall, the host does not pass packets between the networks that are attached to the host. However, the host can still provide standard TCP/IP services, such as ftp or rlogin, to authorized users.
Because TCP/IP considers any machine with multiple network interfaces to be a router, you need to perform a few operations to turn the machine into a multihomed host.
Become superuser on the prospective multihomed host.
Create an /etc/hostname.interface file for each additional network interface that is installed in the machine.
Type the following:
% touch /etc/notrouter
This command creates an empty file that is called /etc/notrouter.
Reboot the machine.
When the machine reboots, the startup script checks for the presence of the /etc/notrouter file. If the file exists, the startup script does not run in.routed -s or in.rdisc -r. The file also does not turn on IP forwarding on all interfaces that are configured “up” by ifconfig. This process happens regardless of whether an /etc/gateways file exists. Thus the machine is now a multihomed host.
Space-saving mode provides the host with a table that contains only the default routes. On a host, in.routed runs with space-saving mode turned off by default.
If the host is not to have a full routing table (which provides increased protection against misconfigured routers), turn space-saving mode on.
Become superuser on the host.
Edit the /etc/rc2.d/S69inet startup script by adding to the line /usr/sbin/in.routed -q the -s option:
/usr/sbin/in.routed -q -s |
to
/usr/sbin/in.routed -q -S |
For reasons that involve router reliability, you might not want your hosts to use RDISC. If the automatic selection of RIP rather than RDISC by a host is to work reliably, the routers in the network (particularly those that run RDISC) must also work reliably.
If your routers are not running RDISC and you install a single Solaris router, by default all hosts that are connected to that router rely on that router alone. To have the hosts on that network use the other routers as well, turn off RDISC on the new router.
Task |
Description |
For Instructions, Go To ... |
---|---|---|
Turn off ICMP router discovery on the host |
Involves changing the name of the host's in.rdisc file | |
Turn off ICMP router discovery on the router |
Involves changing the name of the router's in.rdisc file |
Become superuser on the host.
Change the name of the host's /usr/sbin/in.rdisc to some other name, such as /usr/sbin/in.rdisc.saved.
Reboot the host.
Become superuser on the router.
Change the name of the router's /usr/bin/in.rdisc file to some other file name.
Reboot the router.
One of the first signs of trouble on the network is a loss of communications by one or more hosts. If a host refuses to come up at all the first time that the host is added to the network, the problem might be in one of the configuration files. The problem might also be a faulty network interface card. If a single host suddenly develops a problem, the network interface might be the cause. If the hosts on a network can communicate with each other but not with other networks, the problem could lie with the router, or the problem could be in another network.
You can use the ifconfig program to obtain information on network interfaces and netstat to display routing tables and protocol statistics. Third-party network diagnostic programs provide a number of troubleshooting utilities. Refer to third-party documentation for information.
Less obvious are the causes of problems that degrade performance on the network. For example, you can use tools such as ping to quantify problems such as the loss of packets by a host.
If the network has problems, diagnose and fix software-related problems by acting in one of the following ways:
Check the hosts database (and ipnodes if you are using IPv6) to ensure that the entries are correct and current.
If you are running RARP, check the Ethernet addresses in the ethers database to ensure that the entries are correct and current.
Try to connect to the local host by using telnet.
Ensure that the network daemon inetd is running. Log in as superuser and type the following:
# ps -ef | grep inetd
The following example shows the output when the inetd daemon is running:
root 57 1 0 Apr 04 ? 3:19 /usr/sbin/inetd -s root 4218 4198 0 17:57:23 pts/3 0:00 grep inetd |
Use the ping command to find out whether an IP connection exists for a particular host. The basic syntax is:
/usr/sbin/ping host [timeout]
In this syntax, host is the host name of the machine in question. The optional timeout argument indicates the time in seconds for ping to continue trying to reach the machine—20 seconds by default. The ping(1M) man page describes additional syntaxes and options.
When you run ping, the ICMP protocol sends a datagram to the host you specify, asking for a response. ICMP is the protocol responsible for error handling on a TCP/IP network. See ICMP Protocol for details.
Task |
Description |
For Instructions, Go To ... |
---|---|---|
Determine if a host is running |
Involves pinging the hostname | |
Determine if a host is losing packets |
Involves using the -s option of the ping command |
On the command line, type the following command.
% ping hostname |
If host hostname is up, this message is displayed:
hostname is alive |
This message indicates that hostname responded to the ICMP request. However, if hostname is down or cannot receive the ICMP packets, you receive the following response from ping:
no answer from hostname |
If you suspect that a machine might be losing packets even though the machine is running, you can use the s option of ping to try to detect the problem.
On the command line, type the following command.
% ping -s hostname |
ping continually sends packets to hostname until you send an interrupt character or a timeout occurs. The responses on your screen resemble the following:
PING elvis: 56 data bytes 64 bytes from 129.144.50.21: icmp_seq=0. time=80. ms 64 bytes from 129.144.50.21: icmp_seq=1. time=0. ms 64 bytes from 129.144.50.21: icmp_seq=2. time=0. ms 64 bytes from 129.144.50.21: icmp_seq=3. time=0. ms . . . ----elvis PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/20/80 |
The packet-loss statistic indicates whether the host has dropped packets.
If ping fails, check the status of the network that is reported by ifconfig and netstat, as described in ifconfig Command and netstat Command.
The ifconfig command displays information about the configuration of an interface that you specify. Refer to the ifconfig(1M) man page for details. The syntax of ifconfig follows:
ifconfig interface-name [protocol_family]
Task |
Description |
For Instructions, Go To ... |
---|---|---|
Get information about a specific interface |
Involves using the ifconfig command | |
Get information about all interfaces on a network |
Involves using the -a option of the ifconfig command |
For an le0 interface, your output resembles the following:
le0: flags=863<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 129.144.44.140 netmask ffffff00 broadcast 129.144.44.255 ether 8:0:20:8:el:fd |
The previous flags section shows that the interface is configured “up,” capable of broadcasting, and not using “trailer” link-level encapsulation. The mtu field tells you that this interface has a maximum transfer size of 1500 octets. Information on the second line includes the IP address of the host you are using, the netmask being currently used, and the IP broadcast address of the interface. The third line gives the machine address (Ethernet, in this instance) of the host.
A useful ifconfig option is -a, which provides information on all interfaces on your network.
This command produces, for example:
le0: flags=49<UP,LOOPBACK,RUNNING> mtu 8232 inet 127.144.44.140 netmask ff000000 le0:flags=863<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 129.144.44.140 netmask ffffff00 broadcast 129.144.44.255 ether 8:0:20:8:el:fd |
Output that indicates an interface is not running might mean a problem with that interface. In this instance, see the ifconfig(1M) man page.
The netstat command generates displays that show network status and protocol statistics. You can display the status of TCP and UDP endpoints in table format, routing table information, and interface information.
netstat displays various types of network data, depending on the command-line option that is selected. These displays are the most useful for system administration. The syntax for this form follows:
netstat [-m] [-n] [-s] [-i | -r] [-f address_family]
The most frequently used options for determining network status are s, r, and i. See the netstat(1M) man page for a description of the options.
Task |
Description |
For Instructions, Go To ... |
---|---|---|
Display statistics by protocol |
Involves using the -s option of the netstat command | |
Display network interface status |
Involves using the -i option of the netstat command | |
Display routing table status |
Involves using the -r option of the netstat command |
The netstat -s option displays by protocol statistics for the UDP, TCP, ICMP, and IP protocols.
On the command line, type the following command.
% netstat -s |
The result resembles the display that is shown in the following example. (Parts of the output have been truncated.) The information can indicate areas where a protocol is having problems. For example, statistical information from ICMP can indicate where this protocol has found errors.
UDP udpInDatagrams = 39228 udpOutDatagrams = 2455 udpInErrors = 0 TCP tcpRtoAlgorithm = 4 tcpMaxConn = -1 tcpRtoMax = 60000 tcpPassiveOpens = 2 tcpActiveOpens = 4 tcpEstabResets = 1 tcpAttemptFails = 3 tcpOutSegs = 315 . . IP ipForwarding = 2 ipDefaultTTL = 255 ipInReceives = 4518 ipInHdrErrors = 0 . . ICMP icmpInMsgs = 0 icmpInErrors = 0 icmpInCksumErrs = 0 icmpInUnknowns = 0 . . IGMP: 0 messages received 0 messages received with too few bytes 0 messages received with bad checksum 0 membership queries received 0 membership queries received with invalid field(s) 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 membership reports sent |
The i option of netstat shows the state of the network interfaces that are configured with the machine where you ran the command.
On the command line, type the following command:
% netstat -i |
netstat -i produced the following sample display:
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue le0 1500 b5-spd-2f-cm tatra 14093893 8492 10174659 1119 2314178 0 lo0 8232 loopback localhost 92997622 5442 12451748 0 775125 0 |
Using this display, you can determine the number of packets a machine transmits and receives on each network. For example, the input packet count (Ipkts) that are displayed for a server can increase each time a client tries to boot, while the output packet count (Opkts) remains steady. This outcome suggests that the server is seeing the boot request packets from the client, but does not realize that the server is supposed to respond to them. This confusion might be caused by an incorrect address in the hosts, ipnodes, or ethers database.
However, if the input packet count is steady over time, then the machine does not see the packets at all. This outcome suggests a different type of failure, possibly a hardware problem.
The -r option of netstat displays the IP routing table.
On the command line, type the following command.
% netstat -r |
netstat -r produces the following sample display on machine tenere:
Routing tables Destination Gateway Flags Refcnt Use Interface temp8milptp elvis UGH 0 0 irmcpeb1-ptp0 elvis UGH 0 0 route93-ptp0 speed UGH 0 0 mtvb9-ptp0 speed UGH 0 0 . mtnside speed UG 1 567 ray-net speed UG 0 0 mtnside-eng speed UG 0 36 mtnside-eng speed UG 0 558 mtnside-eng tenere U 33 190248 le0 |
The first column shows the destination network, the second the router through which packets are forwarded. The U flag indicates that the route is up. The G flag indicates that the route is to a gateway. The H flag indicates that the destination is a fully qualified host address, rather than a network.
The Refcnt column shows the number of active uses per route, and the Use column shows the number of packets sent per route. Finally, the Interface column shows the network interface that the route uses.
If you suspect a routing daemon malfunction, you can log its actions, including all packet transfers when you start up the routed daemon.
Become superuser.
Create a log file of routing daemon actions by typing the following command at a command-line prompt.
# /usr/sbin/in.routed /var/logfilename |
On a busy network, this command can generate almost continuous output.
You can use snoop to capture network packets and display their contents. Packets can be displayed as soon as they are received, or saved to a file. When snoop writes to an intermediate file, packet loss under busy trace conditions is unlikely. snoop itself is then used to interpret the file. For information about using the snoop command, refer to the snoop(1M) man page.
The snoop command must be run by root (#) to capture packets to and from the default interface in promiscuous mode. In summary form, only the data that pertains to the highest-level protocol is displayed. For example, an NFS packet only displays NFS information. The underlying RPC, UDP, IP, and Ethernet frame information is suppressed but can be displayed if either of the verbose options is chosen.
The snoop capture file format is described in RFC 1761.
snoop server client rpc rstatd collects all RPC traffic between a client and server, and filters the traffic for rstatd.
Task |
Description |
For Instructions, Go To ... |
---|---|---|
Check all packets from your system |
Involves using the netstat and snoop commands and interpreting the results | |
Capture snoop results to a file |
Involves using the -o option of the snoop command | |
Check packets between server and client |
Involves saving the results of the snoop command to a file and inspecting the results |
Become superuser.
Type the following command at the command-line prompt to find the interfaces that are attached to the system.
# netstat -i |
snoop normally uses the first non-loopback device (le0).
Type snoop.
Use Control-C to halt the process.
# snoop Using device /dev/le (promiscuous mode) maupiti -> atlantic-82 NFS C GETATTR FH=0343 atlantic-82 -> maupiti NFS R GETATTR OK maupiti -> atlantic-82 NFS C GETATTR FH=D360 atlantic-82 -> maupiti NFS R GETATTR OK maupiti -> atlantic-82 NFS C GETATTR FH=1A18 atlantic-82 -> maupiti NFS R GETATTR OK maupiti -> (broadcast) ARP C Who is 120.146.82.36, npmpk17a-82 ? |
Interpret the results.
In the example, client maupiti transmits to server atlantic-82 by using NFS file handle 0343. atlantic-82 acknowledges with OK. The conversation continues until maupiti broadcasts an ARP request that asks who is 120.146.82.36?
This example demonstrates the format of snoop. The next step is to filter snoop to capture packets to a file.
Interpret the capture file by using details that are described in RFC 1761.
Become superuser.
On the command line, type the following command.
# snoop -o filename |
For example:
# snoop -o /tmp/cap Using device /dev/le (promiscuous mode) 30 snoop: 30 packets captured |
By using this command, you have captured 30 packets in a file /tmp/cap. The file can be anywhere with enough disk space. The number of packets that are captured is displayed on the command line, enabling you to press Control-C to abort at any time.
snoop creates a noticeable networking load on the host machine, which can distort the results. To see the actual results, run snoop from a third system (see the next section).
On the command line, type the following command to inspect the file.
# snoop -i filename |
For example:
# snoop -i /tmp/cap 1 0.00000 frmpk17b-082 -> 224.0.0.2 IP D=224.0.0.2 S=129.146.82.1 LEN=32, ID=0 2 0.56104 scout -> (broadcast) ARP C Who is 129.146.82.63, grail ? 3 0.16742 atlantic-82 -> (broadcast) ARP C Who is 129.146.82.76, honeybea ? 4 0.77247 scout -> (broadcast) ARP C Who is 129.146.82.63, grail ? 5 0.80532 frmpk17b-082 -> (broadcast) ARP C Who is 129.146.82.92, holmes ? 6 0.13462 scout -> (broadcast) ARP C Who is 129.146.82.63, grail ? 7 0.94003 scout -> (broadcast) ARP C Who is 129.146.82.63, grail ? 8 0.93992 scout -> (broadcast) ARP C Who is 129.146.82.63, grail ? 9 0.60887 towel -> (broadcast) ARP C Who is 129.146.82.35, udmpk17b-82 ? 10 0.86691 nimpk17a-82 -> 129.146.82.255 RIP R (1 destinations) |
Refer to specific protocol documentation for detailed analysis and recommended parameters for ARP, IP, RIP and so forth. The Web contains a number of requests for comments.
Establish a snoop system off a hub that is connected to either the client or server.
The third system (the snoop system) checks all the intervening traffic, so the snoop trace reflects what is actually happening on the wire.
Become superuser.
On the command line, type snoop with options and save to a file.
Inspect and interpret results.
Look at RFC 1761 for details of the snoop capture file.
Use snoop frequently and consistently to become familiar with normal system behavior. For assistance in analyzing packets, look for a recent white paper and RFC, and seek the advice of an expert in a particular area, such as NFS or YP. For details on using snoop and its options, refer to the snoop(1M) man page.
Use the traceroute utility to trace the route an IP packet follows to some Internet host. The traceroute utility utilizes the IP protocol (time-to-live) ttl field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path. This utility also attempts to elicit the response PORT_UNREACHABLE (or ECHO_REPLY) from the destination host. The traceroute utility sends probes with a ttl of one and increases by one until the intended host is found or has incremented beyond the maximum number of intermediate hosts.
The traceroute utility is especially useful for determining routing misconfiguration and routing path failures. If a particular host is unreachable, you can use the traceroute utility to see what path the packet follows to the intended host and where possible failures might occur.
The traceroute utility also displays the round trip time for each gateway along the path to the target host. This information can be useful for analyzing where traffic is slow between the two hosts.
On the command line, type the following command.
% traceroute destination-hostname |
For details of the traceroute utility, see the traceroute(1M) man page.
The following sample of the traceroute command shows the seven–hop path a packet follows from the host istanbul to the host sanfrancisco, along with the times for a packet to traverse each hop.
istanbul% traceroute sanfrancisco traceroute: Warning: Multiple interfaces found; using 172.31.86.247 @ le0 traceroute to sanfrancisco (172.29.64.39), 30 hops max, 40 byte packets 1 frbldg7c-86 (172.31.86.1) 1.516 ms 1.283 ms 1.362 ms 2 bldg1a-001 (172.31.1.211) 2.277 ms 1.773 ms 2.186 ms 3 bldg4-bldg1 (172.30.4.42) 1.978 ms 1.986 ms 13.996 ms 4 bldg6-bldg4 (172.30.4.49) 2.655 ms 3.042 ms 2.344 ms 5 ferbldg11a-001 (172.29.1.236) 2.636 ms 3.432 ms 3.830 ms 6 frbldg12b-153 (172.29.153.72) 3.452 ms 3.146 ms 2.962 ms 7 sanfrancisco (172.29.64.39) 3.430 ms 3.312 ms 3.451 ms |