Network Interfaces

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.



Part I: Solaris 9 Operating Environment, Exam I