Network Interfaces
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.
Interface Configuration
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.
Network Troubleshooting
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:
$ traceroute www.sun.com
Tracing route to wwwwseast.usec.sun.com [192.9.49.30]
over a maximum of 30 hops:
1 184 ms 142 ms 138 ms 202.10.4.131
2 147 ms 144 ms 138 ms 202.10.4.129
3 150 ms 142 ms 144 ms 202.10.1.73
4 150 ms 144 ms 141 ms atm11-0-0-11.ia4.optus.net.au [202.139.32.17]
5 148 ms 143 ms 139 ms 202.139.1.197
6 490 ms 489 ms 474 ms hssi9-0-0.sf1.optus.net.au [192.65.89.246]
7 526 ms 480 ms 485 ms g-sfd-br-02-f12-0.gn.cwix.net [207.124.109.57]
8 494 ms 482 ms 485 ms core7-hssi6-0-0.SanFrancisco.cw.net
[204.70.10.9]
9 483 ms 489 ms 484 ms corerouter2.SanFrancisco.cw.net [204.70.9.132]
10 557 ms 552 ms 561 ms xcore3.Boston.cw.net [204.70.150.81]
11 566 ms 572 ms 554 ms sun-micro-system.Boston.cw.net
[204.70.179.102]
12 577 ms 574 ms 558 ms wwwwseast.usec.sun.com [192.9.49.30]
Trace complete.
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.
No comments:
Post a Comment