Because all network operations require access to a network interface, it’s important to understand how to manage the interface and troubleshoot it when necessary. In the following sections, we examine how to configure a network interface, manually stop and start interfaces, and set key transmission parameters. In addition, we investigate the use of the netstat command to troubleshoot network configurations with respect to the IP, TCP, UDP, and ICMP protocols.
The current configuration for a network interface can always be displayed by using the ifconfig command. For example, to display the parameters for all of the interfaces installed on a local system, the following command could be used:
# ifconfig -a lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232 inet 127.0.0.1 netmask ff000000 hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 192.68.24.16 netmask ffffff00 broadcast 192.68.24.255
This example shows two interfaces: the loopback interface, which handles internal connections, and the hme0 interface, which handles all external connections. The hme0 interface has the IP address 192.68.24.16, clearly belonging to the Class C network 192.68.24.0. Thus, a Class C netmask is specified in hex (ffffff00), and the broadcast address is given as the highest numbered slot in the 192.68.24.0 network (that is, 192.68.24.255). In addition, the interface is noted as UP as opposed to DOWN. To display information for a specific interface, the following command could be used:
# ifconfig hme0 hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 192.17.128.16 netmask ffffff00 broadcast 192.17.128.255 ether 8:0:18:6:e1:b2
In this example, the /etc/ethers database contains an entry for 192.17.128.16, so a MAC address for the interface is also displayed. In addition to displaying the configuration and status of a network interface, the ifconfig command can be used to bring an interface up, or take it down. While this operation is typically performed manually at boot time, there are occasions where it is necessary to perform this operation manually. For example, if an attack is detected through a remote access connection, the interface can be disabled rapidly, after which patches can be applied or some other remedial action performed before the interface is bought back up. For example to bring the hme0 interface down, the following command is used:
# ifconfig hme0 down
To verify the status of the interface, the ifconfig command can be used once again:
# ifconfig hme0 hme0: flags=863<DOWN,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 192.68.24.16 netmask ffffff00 broadcast 192.68.24.255
The DOWN flag is now noted in the status, and no incoming or outgoing connections will be accepted. Bringing an interface down will impact on all services that use that interface. Some daemons will handle the disruption gracefully, while others may terminate after a connection timeout. To bring the interface back up again, the following command is used:
# ifconfig hme0 up
Again, the UP status of the network interface can be verified by using the ifconfig command:
# ifconfig hme0 hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 192.68.24.16 netmask ffffff00 broadcast 192.68.24.255
If you want to modify the operational settings of the TCP device /dev/tcp, the ndd command can be used. A wide range of parameters can be set, including IP forwarding, various connection intervals and timeouts, and buffer sizes. To view the current values, the following command can be used:
# ndd /dev/tcp \?
Parameters can also be set to new values by using the –set option. For example, to disable IPv4 packet forwarding, the following command would be used:
# ndd -set /dev/ip ip_forwarding 0
If you make changes that need to be made permanent, the /etc/rc2.d/S69inet file should be modified to include the new ndd line.
One of the most difficult issues in network troubleshooting is determining exactly where the problem lies. For example, a user may complain that they’ve lost Internet access, but there may potentially be 20 or 30 hosts lying between the client and server systems: how is it possible to determine where the fault lies? The first step is to use the ping command to see if a host is reachable. This command attempts to make a connection to a remote host by sending off an ICMP echo request and waiting 20 seconds for a response. If no response is received, an error message is reported. However, if the host is reachable, the following message will be displayed:
$ ping cyclops.cassowary.net cyclops.cassowary.net is alive
It is also possible to examine relative response latencies by pinging the remote host every second and seeing if there is a lot of variability:
$ ping -s cyclops.cassowary.net PING cyclops.cassowary.net: 56 data bytes 64 bytes from cyclops.cassowary.net(192.128.205.2):icmp_seq=0.time=1.ms 64 bytes from cyclops.cassowary.net(192.128.205.2):icmp_seq=1.time=0.ms 64 bytes from cyclops.cassowary.net(192.128.205.2):icmp_seq=2.time=10.ms ... ---- cyclops.cassowary.net PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/2/10
Here, we can see that there is a lot of variability in response times, with some taking up to ten times longer than others. This may indicate a high level of traffic, which is causing collisions. One solution would be to upgrade the speed of the local cabling and network interfaces used. Alternatively, subnets could be created to reduce the amount of data being transmitted around the local network.
If the connection is believed to be broken, the traceroute command can be used to isolate which intermediate host is failing. The following traceroute command shows a successful connection to the Sun web server:
If one or more intermediate hosts fails to respond within 5 seconds, then a * would be displayed. For example, if the host xcore3.Boston.cw.net did not respond to three requests, that line of display would look like this:
10 * * * xcore3.Boston.cw.net [204.70.150.81]
Alternatively, if the host was completely unreachable, the following output would be displayed:
10 * * !H xcore3.Boston.cw.net [204.70.150.81]
The administrator of xcore3.Boston.cw.net should then be contacted to determine the nature of the problem.
If the connection fails on the first hop, the problem might be local. In this case, the netstat command should be used to determine the status of all network interfaces on the local system. Let’s look at an example:
# netstat -i Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue lo0 8232 loopback localhost 434332 0 434332 0 0 0 hme0 1500 192.128.205.2 chaos 43234544 554533 43789077 0 0 0
This example shows the host chaos with the IP address 192.128.205.2. Although there were no outbound packet errors (Oerrs), there were a number of inbound packet errors (Ierrs). An alternative view is provided on a per-protocol basis for the TCP, ICMP, and UDP protocols:
# netstat -s UDP udpInDatagrams =502856 udpInErrors = 0 udpOutDatagrams =459357 TCP tcpRtoAlgorithm = 4 tcpRtoMin = 200 tcpRtoMax =240000 tcpMaxConn = -1 tcpActiveOpens = 33786 tcpPassiveOpens = 12296 tcpAttemptFails = 324 tcpEstabResets = 909 tcpCurrEstab = 384 tcpOutSegs =19158723 tcpOutDataSegs =13666668 tcpOutDataBytes =981537148 tcpRetransSegs = 33038 tcpRetransBytes =41629885 tcpOutAck =5490764 tcpOutAckDelayed =462511 tcpOutUrg = 51 tcpOutWinUpdate = 456 tcpOutWinProbe = 290 tcpOutControl = 92218 tcpOutRsts = 1455 tcpOutFastRetrans = 18954 tcpInSegs =15617893 tcpInAckSegs =9161810 tcpInAckBytes =981315052 tcpInDupAck =4559921 tcpInAckUnsent = 0 tcpInInorderSegs =5741788 tcpInInorderBytes =1120389303 tcpInUnorderSegs = 25045 tcpInUnorderBytes =16972517 tcpInDupSegs =4390218 tcpInDupBytes =4889714 tcpInPartDupSegs = 375 tcpInPartDupBytes =130424 tcpInPastWinSegs = 17 tcpInPastWinBytes =1808990872 tcpInWinProbe = 162 tcpInWinUpdate = 270 tcpInClosed = 313 tcpRttNoUpdate = 28077 tcpRttUpdate =9096791 tcpTimRetrans = 18098 tcpTimRetransDrop = 26 tcpTimKeepalive = 509 tcpTimKeepaliveProbe= 76 tcpTimKeepaliveDrop = 1 tcpListenDrop = 0 tcpListenDropQ0 = 0 tcpHalfOpenDrop = 0 IP ipForwarding = 2 ipDefaultTTL = 255 ipInReceives =16081438 ipInHdrErrors = 8 ipInAddrErrors = 0 ipInCksumErrs = 1 ipForwDatagrams = 0 ipForwProhibits = 2 ipInUnknownProtos = 274 ipInDiscards = 0 ipInDelivers =16146712 ipOutRequests =19560145 ipOutDiscards = 0 ipOutNoRoutes = 0 ipReasmTimeout = 60 ipReasmReqds = 0 ipReasmOKs = 0 ipReasmFails = 0 ipReasmDuplicates = 0 ipReasmPartDups = 0 ipFragOKs = 7780 ipFragFails = 0 ipFragCreates = 40837 ipRoutingDiscards = 0 tcpInErrs = 291 udpNoPorts =144065 udpInCksumErrs = 2 udpInOverflows = 0 rawipInOverflows = 0 ICMP icmpInMsgs = 17469 icmpInErrors = 0 icmpInCksumErrs = 0 icmpInUnknowns = 0 icmpInDestUnreachs = 2343 icmpInTimeExcds = 26 icmpInParmProbs = 0 icmpInSrcQuenchs = 0 icmpInRedirects = 19 icmpInBadRedirects = 19 icmpInEchos = 9580 icmpInEchoReps = 5226 icmpInTimestamps = 0 icmpInTimestampReps = 0 icmpInAddrMasks = 0 icmpInAddrMaskReps = 0 icmpInFragNeeded = 0 icmpOutMsgs = 11693 icmpOutDrops =140883 icmpOutErrors = 0 icmpOutDestUnreachs = 2113 icmpOutTimeExcds = 0 icmpOutParmProbs = 0 icmpOutSrcQuenchs = 0 icmpOutRedirects = 0 icmpOutEchos = 0 icmpOutEchoReps = 9580 icmpOutTimestamps = 0 icmpOutTimestampReps= 0 icmpOutAddrMasks = 0 icmpOutAddrMaskReps = 0 icmpOutFragNeeded = 0 icmpInOverflows = 0
Again, specific error counters such as icmpOutErrors, udpInErrors, and tcpInDupBytes should be regularly reviewed to ensure that error rates do not approach the total number of packets being transferred in or out of an interface.