Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)

Solaris network configuration

News See Also Recommended Links Administering Logical Network Interfaces Quiz Default  Router Troubleshooting Solaris Network Problems Solaris Snoop Packet Sniffer
Solaris Multipathing Solaris ndd Solaris getent Command Solaris Network Certification Solaris route command netstat Humor Etc

Lecture Notes from my FDU class (largely based on Sun Solaris Student Guide materials and O'Reilly books).


Two methods of getting MAC address:

  1. Using ifconfig -a command  
  2. Getting MAC address from boot prompt:  ok banner

Test question: Which three statements identify information which is displayed by the ifconfig -a command? (Choose three.)


ping command can be used to check and display network connectivity. To use ping the following five conditions must be met:

  1. The interface must be plumbed.
  2. The interface must be configured.
  3. The interface must be up.
  4. The interface must be physically connected.
  5. The interface must have valid routes configured.

Changing the hostname

On Solaris the hostname of a system is contained in (at least) six files, which all need to be changed to change the host name of the system ( there can be multiple  /etc/hostname.xxn  files; one for each networking interface):

  1. /etc/nodename
  2. All  /etc/hostname.xxn files (can be more then one)
  3. /etc/inet/hosts
  4. Three /etc/net/tic* files:
    1. /etc/net/ticlts/hosts
    2. /etc/net/ticots/hosts
    3. /etc/net/ticotsord/hosts


Snoop can be used for monitoring network traffic. It switches interface into promiscuous mode. Most important options include:

Note: Press Control-C to stop the snoop utility.  For more information see Solaris Snoop Packet Sniffer

The purpose of this lecture is to give you some understanding of how to set up Solaris network interfaces using the command-line interface. Also included are some basic troubleshooting hints.

The network interfaces that a system uses to communicate with other  systems on the network use both hardware and software configuration components. When adding a network interface to a system, you must configure specific files to establish a relationship between the hardware and the software addresses.


Sysadmin needs to be able: 

  1. To use the ifconfig command,
  2. To use the ping command,
  3. To use the snoop command,
  4. Control and monitor the functionality of network interfaces,
  5. Display MAC address and IP address, netmask, and routing table
  6. Configure interfaces at boot time.

In order to enable a network interface under Solaris, several steps may be necessary. These include:

An IP address is for each interface is stored in the hostname file, located in the /etc  directory. For a system with a single interface (e.g., /dev/bge0), there is one such file. If system has multiple interfaces there are as many files as there are actve interfaces. For example a quad ethernet card (with devices /dev/qfe0, /dev/qfe1, /dev/qfe2, and /dev/qfe3) would have four hostname files containing distinct IP addresses: hostname.qfe0, hostname.qfe1, hostname.qfe2, and hostname.qfe3.

A mulit-homed host allows data to be exchanged only on the local area network (including with the router defined for that network), while a router is responsible for conveying packets between networks. To prevent routing, a multi-homed host must touch the file /etc/notrouter. In addition, the default router for the local network should have its IP address inserted into the file /etc/defaultrouter.

You can create a hosts entry for each interface in the /etc/hosts file or by inserting a record into whatever distributed naming service is mandated by /etc/nsswitch.conf. For example, if the IP address contained in hostname.qfe0, hostname.qfe1, hostname.qfe2, and hostname.qfe3  were to be mapped to the hostnames www1, www2, www3,  and www4, the /etc/hosts  file would contain the following entries:

# cat /etc/hosts

Alternatively, if DNS is being used (as shown in Chapter 5), the following entries would need to be made in the appropriate zone file:

www1   IN   A   ;webserver 
www2   IN   A   ;webserver 
www3   IN   A   ;webserver 
www4   IN   A   ;webserver 

Each interface needs to be plumbed before it can pass and receive IP traffic. Once the device is plumbed, its runtime parameters, such as its IP address, can also be configured by using the ifconfig  command:

# /usr/sbin/ifconfig hme0 broadcast netmask 255.255.

To bring up the interface, the up  keyword must be used:

# /usr/sbin/ifconfig hme0 up

All of these individual commands can be combined into the following command, which configures the hardware, sets all parameters, and brings up the interface:

# /usr/sbin/ifconfig hme0 broadcast netmask plumb up

In order to determine whether the interfaces are being addressed correctly by other hosts on the local network, use the arp  command to display all active connections between the localhost and other hosts:

# /usr/sbin/arp -a

Net to Media Table: IPv4
Device   IP Address               Mask      Flags   Phys Addr
------ -------------------- --------------- ----- ---------------
hme0   hp                00:50:ba:13:08:18
hme0   austin      SP    00:03:ba:04:a4:e8
hme0         SM    01:00:5e:00:00:00

This displays the ethernet address to IP address mapping for the local host. The flags displayed include:

Once the interface has been enabled, the ifconfig command can be used to view all active interfaces:

# /usr/sbin/ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet netmask ffffff00 broadcast
lo0: flags=2000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1
        inet6 ::1/128
hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
        inet6 fe80::203:baff:fe04:a4e8/10

Obtaining Ethernet Card(s) MAC Address

The media access control (MAC) address is your computerís unique hardware address on a local area network (LAN). The MAC address is also the Ethernet address on an Ethernet LAN. When you are connected  to a LAN, an address resolution table maps your computerís physical  MAC address to an Internet Protocol (IP) address on the LAN. Two ways  to display the MAC address or the Ethernet address are:

Note Ė The MAC address is displayed only if the root user issues the ifconfig command. Only the IP address information is displayed if a  non-root user issues the ifconfig command.

You can also retrieve the MAC address from a system that has not yet  been booted by performing the banner command at the ok prompt:

          ok banner

IP Address

The ifconfig command displays the current configuration for one of all network (he -a option) interfaces.

 Changing status on an Ethernet Interface(Up/Down)

When an Ethernet interface is marked as down, it means that it cannot communicate. You can use the ifconfig command to change status of the interface: mark it up or down. For example, to mark the hme0 interface as down use the commands:

# ifconfig hme0 down && ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet netmask ff000000
hme0: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet netmask ffffff00 broadcast
ether 8:0:20:93:c9:af

Note Ė After to take interface down UP flag should no longer be present. When an interface is flagged as UP, it is ready to communicate.

When you mark an interface as up, the UP status appears in the flags field of the ifconfig command output:

# ifconfig hme0 up
# ifconfig -a
lo0: flags=1000849<UP...

The following conditions must be satisfied: for the ping command to succeed in solaris environment: 

Capturing Network Traffic

Snoop utility can capture network packets. This utility is similar to tcpdump and output formats are almost identical. You can use the snoop utility to see what happens when one system tries to communicate with another system. For example the command to view network traffic between two specific systems alpha and beta  is:

# snoop alpha, beta

Snoop options include:

Note: Use the -a option to enable audible clicks, which notify you of any network traffic. Although noisy, the clicks are useful when troubleshooting, for example: snoop -a dhcp

Configuring Network Interfaces

Network interfaces in Solaris are controlled by three files: 

  1. The /etc/rcS.d/ file
  2. The /etc/hostname.xxnfile
  3.  The /etc/inet/hosts file

The /etc/rcS.d/ File

The /etc/rcS.d/ file is one of the startup scripts.  The script searches for files called hostname.xxn in the /etc directory, where xx  is an interface type and n is the instance of the interface. For every file named /etc/hostname.xxn, the script uses the ifconfig command with the plumb option to make the kernel ready to talk to this type of interface. The script then configures the named interface with an IP address and other required network information.. For example /etc/hostname.hme0 is a file used to configure hme0 interface.

Note:  The /etc/rcS.d/ file first appeared in the Solaris 8.

The /etc/hostname.xxn File

The /etc/hostname.xxn  file contains an entry for the configuration of a corresponding interface. The  xxn component  of the file name is replaced by an interface type and a number that differentiates between multiple interfaces of the same type present in the system.  For example:

The xx codes for the interface types are product codes. For example, the le code is an abbreviation of the Lance Ethernet, and the qfe code is an abbreviation for Quadfast Ethernet.

The /etc/hostname.hme0 file should contain either the host name or the IP address of the system that contains the hme0 interface. The host name contained in the file must exist in the /etc/hosts file so that it can be  resolved to an IP address at system boot time. You can edit the  /etc/hostname.hme0 file to contain either the host name or the IP  address from the /etc/hosts file, for example:

# cat /etc/hostname.hme0

The /etc/inet/hosts File

The /etc/inet/hosts file is a local database that associates the IP addresses of hosts with their names. You can use the /etc/inet/hosts file with, or instead of, other hosts databases, including the Domain Name System (DNS), the Network Information Service (NIS) hosts map, and the Network Information Service Plus (NIS+) hosts table. Programs use library interfaces to access information in the /etc/inet/hosts file.

The /etc/inet/hosts file contains at least the loopback and host information. The file has one entry for each IP address of each host. If a host has more than one IP address, this file will have one entry for each address, on separate lines. The format of each line is:

IP-address official-host-name [nicknames] . . .

Items are separated by any number of space or tab characters. The first item on a line is the hostís IP address. The second entry is the hostís official name. Subsequent entries on the same line are alternative names for the same machine, or nicknames. Nicknames are optional.  For a host with more than one IP address, consecutive entries for these
addresses will contain different host names.

# cat /etc/inet/hosts
< output truncated>
.    localhost
< output truncated>

Note Ė The /etc/inet/hosts file is the official POSIX location of the hosts file. The symbolic link /etc/hosts exists for Berkeley Software Distribution (BSD) compatibility.

Changing the Hostname

You must modify following files to successfully change a systemís hostname:

  1. The /etc/nodename file
  2. All the /etc/hostname.xxn file
  3. The /etc/inet/hosts file
  4. The /etc/net/ticlts/hosts file
  5. The /etc/net/ticots/hosts file
  6. The /etc/net/ticotsord/hosts file

Editing the /etc/nodename File. Each Solaris OE has a canonical name, which is the official name used when referring to a system. By convention, the system name is the same as the host name associated with the IP address of the primary network interface; for example, hostname.hme0. The following example shows a systemís /etc/nodename file:

# cat /etc/nodename

You can change the canonical name by editing the /etc/nodename file,  and rebooting the system. If the machineís network configuration is managed remotely and  delivered by the DHCP or remote procedure calls (RPC) bootparams protocols, the /etc/nodename file is not used. The file is not used because the remote service delivers the canonical name.

Editing the /etc/hostname.xxn File. The /etc/hostname.xxn file contains either the host name or the IP address of the system that contains the named interface.

Editing the /etc/inet/hosts File. Network addresses are written in the conventional decimal-dot notation.  Host names are text strings up to 24 characters. Alphabetic characters,  numbers, the minus sign, and a period are allowed in the host name.  Periods are only allowed when they serve to delimit components of  domain style names. Blanks and spaces are not allowed in the host name. No distinction is made between uppercase and lowercase characters. The  first character must be an alphabetic character. The last character can't  be a minus sign (-) or a dot (.).  This file accept regular shell style comments starting with a pound sign (#). All characters after #, up to the end of the line, are not interpreted. 

Editing the Three Transport Layer Independent (TLI) Files.  The /etc/net directory contains three subdirectories: /etc/net/ticlts, /etc/net/ticots, and /etc/net/ticotsord. Each of these directories contains a hosts file. These files contain configuration information for  transport-independent network services. If these files become corrupted, unpredictable results can occur when trying to resolve the system host name when using network services. In addition, when you execute the /usr/sbin/sys-unconfig command, the system deletes all of the hosts files. If the files get corrupted or deleted, you can use any editor to restore  them. The format of the file is:

hostname hostname

The sys-unconfig Command

/usr/sbin/sys-unconfig command can be used to undo a Solaris system configuration. It restores a systemís configuration to an "as-manufactured" state. The systemís configuration includes a host name, NIS domain name, time zone, IP address, IP subnet mask, and root password.  The sys-unconfig command does the following:

  1. Saves the current /etc/inet/hosts file information in the /etc/inet/hosts.saved file.
  2. If the current /etc/vfstab file contains Network File System (NFS) mount entries, it saves the /etc/vfstab file to the /etc/vfstab.orig file.
  3. Restores the default /etc/inet/hosts file.
  4. Removes the default host name in the /etc/hostname.xxnfiles for all configured interfaces.
  5. Removes the default domain name in the /etc/defaultdomain file.
  6. Restores the time zone to PST8PDT in the /etc/TIMEZONE file.
  7. Resets naming services to local files.
  8. Removes the entries for this host in the /etc/net/tic*/hosts file.
  9. Removes the /etc/inet/netmasks file.
  10. Removes the /etc/defaultrouter file for naming services.
  11. Removes the password set for the root user in the /etc/shadow file.
  12. Removes the /etc/.rootkey file for NIS+.
  13. Executes all system configuration applications. These applications are defined by prior executions of a sysidconfig -a command.
  14. Removes the /etc/resolv.conf file for DNS.
  15. Disables Lightweight Directory Access Protocol (LDAP) by removing:

When the sys-unconfig command is finished, it performs a system shutdown. The sys-unconfig command is a potentially dangerous utility and can only be run by the root user.

When you restart the system, a configuration scripts prompts you to configure the system information. The sys-unconfig command is not available on diskless clients.

Finally, it may be necessary to set some protocol transmission parameters manually to achieve optimal performance. Use the ndd  command to set parameters for TCP, UDP, ARP, and IP. In addition, ndd  can be used to display the list of all current parameter values relating to a specific protocol. For example, to display the parameters currently associated with TCP, use the following command:

# ndd /dev/tcp \?
?                             (read only)
tcp_close_wait_interval       (read and write)
tcp_conn_req_max_q            (read and write)
tcp_conn_req_max_q0           (read and write)
tcp_conn_req_min              (read and write)
tcp_conn_grace_period         (read and write)
tcp_cwnd_max                  (read and write)
tcp_debug                     (read and write)
tcp_smallest_nonpriv_port     (read and write)
tcp_ip_abort_cinterval        (read and write)
tcp_ip_abort_linterval        (read and write)
tcp_ip_abort_interval         (read and write)
tcp_ip_notify_cinterval       (read and write)
tcp_ip_notify_interval        (read and write)
tcp_ip_ttl                    (read and write)
tcp_keepalive_interval        (read and write)
tcp_maxpsz_multiplier         (read and write)
tcp_mss_def                   (read and write)
tcp_mss_max                   (read and write)
tcp_mss_min                   (read and write)
tcp_naglim_def                (read and write)
tcp_rexmit_interval_initial   (read and write)
tcp_rexmit_interval_max       (read and write)
tcp_rexmit_interval_min       (read and write)
tcp_wroff_xtra                (read and write)
tcp_deferred_ack_interval     (read and write)
tcp_snd_lowat_fraction        (read and write)
tcp_sth_rcv_hiwat             (read and write)
tcp_sth_rcv_lowat             (read and write)
tcp_dupack_fast_retransmit    (read and write)
tcp_ignore_path_mtu           (read and write)
tcp_rcv_push_wait             (read and write)
tcp_smallest_anon_port        (read and write)
tcp_largest_anon_port         (read and write)
tcp_xmit_hiwat                (read and write)
tcp_xmit_lowat                (read and write)
tcp_recv_hiwat                (read and write)
tcp_recv_hiwat_minmss         (read and write)
tcp_fin_wait_2_flush_interval (read and write)
tcp_co_min                    (read and write)
tcp_max_buf                   (read and write)
tcp_zero_win_probesize        (read and write)
tcp_strong_iss                (read and write)
tcp_rtt_updates               (read and write)
tcp_wscale_always             (read and write)
tcp_tstamp_always             (read and write)
tcp_tstamp_if_wscale          (read and write)
tcp_rexmit_interval_extra     (read and write)
tcp_deferred_acks_max         (read and write)
tcp_slow_start_after_idle     (read and write)
tcp_slow_start_initial        (read and write)
tcp_co_timer_interval         (read and write)
tcp_extra_priv_ports          (read only)
tcp_extra_priv_ports_add      (write only)
tcp_extra_priv_ports_del      (write only)
tcp_status                    (read only)
tcp_bind_hash                 (read only)
tcp_listen_hash               (read only)
tcp_conn_hash                 (read only)
tcp_queue_hash                (read only)
tcp_host_param                (read and write)
tcp_1948_phrase               (write only)

Obtaining Network Statistics

Once all network interfaces are configured as required, use the netstat  command, which is responsible for gathering network statistics of various types, to verify their operational status. This data is gathered by using the interfaces on the local host.

netstat  is able to gather statistics for the following types of data:

In the following sections, we'll review each of these data gathering operations and discuss how each is used to aid in troubleshooting and pinpointing performance issues.

Protocol Statistics

The per-protocol statistics can be divided into several categories:

RAWIP (raw IP) packets
TCP packets
IPv4 packets
ICMPv4 packets
IPv6 packets
ICMPv6 packets
UDP packets
IGMP packets

Each packet type has a specific set of measures associated with it. For example, RAWIP packets have counters that check the number of input (rawipInDatagrams) and output (rawipOutDatagrams) datagrams received since boot. UDP has a corrsponding set of counters that measure the number of input (udpInDatagrams) and output (udpOutDatagrams) datagrams received since boot. In addition to counters of normal events, netstat  reports on error events, such as the number of UDP input (udpInErrors) and the number of UDP output (udpOutErrors) errors. These values should be monitored regularly to ensure that the ratio of error to normal conditions does not increase over time. For example, there are 293 tcpActiveOpens  shown in the following listing, compared to only one tcpAttemptFails  event. If the ratio of tcpAttemptFails  to tcpActiveOpens increases over time for TCP traffic, the appropriate TCP parameters may need to be modified by using ndd, or a network error may need to be diagnosed. Here's a representative set of examples for understanding per-protocol errors for IPv6.

$ netstat -s
IPv6    ipv6Forwarding      =     2     ipv6DefaultHopLimit =   255
        ipv6InReceives      =     0     ipv6InHdrErrors     =     0
        ipv6InTooBigErrors  =     0     ipv6InNoRoutes      =     0
        ipv6InAddrErrors    =     0     ipv6InUnknownProtos =     0
        ipv6InTruncatedPkts =     0     ipv6InDiscards      =     0
        ipv6InDelivers      =    25     ipv6OutForwDatagrams=     0
        ipv6OutRequests     =    42     ipv6OutDiscards     =     2
        ipv6OutNoRoutes     =     0     ipv6OutFragOKs      =     0
        ipv6OutFragFails    =     0     ipv6OutFragCreates  =     0
        ipv6ReasmReqds      =     0     ipv6ReasmOKs        =     0
        ipv6ReasmFails      =     0     ipv6InMcastPkts     =     0
        ipv6OutMcastPkts    =    14     ipv6ReasmDuplicates =     0
        ipv6ReasmPartDups   =     0     ipv6ForwProhibits   =     0
        udpInCksumErrs      =     0     udpInOverflows      =     0
        rawipInOverflows    =     0     ipv6InIPv4          =     0
        ipv6OutIPv4         =     0     ipv6OutSwitchIPv4   =     0
ICMPv6  icmp6InMsgs         =     0     icmp6InErrors       =     0
        icmp6InDestUnreachs =     0     icmp6InAdminProhibs =     0
        icmp6InTimeExcds    =     0     icmp6InParmProblems =     0
        icmp6InPktTooBigs   =     0     icmp6InEchos        =     0
        icmp6InEchoReplies  =     0     icmp6InRouterSols   =     0
        icmp6InRouterAds    =     0     icmp6InNeighborSols =     0
        icmp6InNeighborAds  =     0     icmp6InRedirects    =     0
        icmp6InBadRedirects =     0     icmp6InGroupQueries =     0
        icmp6InGroupResps   =     0     icmp6InGroupReds    =     0
        icmp6InOverflows    =     0
        icmp6OutMsgs        =     8     icmp6OutErrors      =     0
        icmp6OutDestUnreachs=     0     icmp6OutAdminProhibs=     0
        icmp6OutTimeExcds   =     0     icmp6OutParmProblems=     0
        icmp6OutPktTooBigs  =     0     icmp6OutEchos       =     0
        icmp6OutEchoReplies =     0     icmp6OutRouterSols  =     3
        icmp6OutRouterAds   =     0     icmp6OutNeighborSols=     1
        icmp6OutNeighborAds =     0     icmp6OutRedirects   =     0
        icmp6OutGroupQueries=     0     icmp6OutGroupResps  =     4
        icmp6OutGroupReds   =     0

Address Type Statistics

The per-address statistics can be divided into three categories:

Let's look at sample output from the AF_UNIX sockets:

$ netstat -f unix
Active UNIX domain sockets
Address     Type       Vnode       Conn     Local Addr      Remote Addr
30000d03738 stream-ord 30000d1eb78 00000000 /tmp/.X11-unix/X0
30000d038e0 stream-ord 00000000    00000000
30000d03a88 stream-ord 30000ce4a30 00000000 /tmp/jd_sockV6
30000d03c30 stream-ord 30000a62d78 00000000 /dev/kkcv
30000d03dd8 stream-ord 30000a62f50 00000000 /dev/ccv

Here we can see a number of different active sockets using Unix type addressing, such as the X11 server, which has the address 30000d03738.

Multicast Statistics

The multicast statistics option provides an overview of interfaces that are currently listening for multicast broadcasts on the (ALL_HOSTS) address. This is so that packets can be routed appropriately using the router discovery daemon (in.rdisc), discussed in the next section, "Routing." In the following example, both the IPv4 and IPv6 multicast groups are displayed:

$ netstat -g
Group Memberships: IPv4
Interface Group                RefCnt
--------- -------------------- ------
lo0                 1
hme0                 1
Group Memberships: IPv6
If    Group                    RefCnt
----- ------------------------ ------
lo0   ff02::1:ff00:1                1
lo0   ff02::1                       1
hme0  ff02::202                     1
hme0  ff02::1:ff04:a4e8             1
hme0  ff02::1                       2

Routing Statistics

The kernel maintains a table of routes, constructed by the routing daemon, in.routed. The various routes that have been configured are always viewable by checking the routing statistics:

$ netstat -r
Routing Table: IPv4
Destination          Gateway              Flags Ref   Use    Interface
-------------------- -------------------- ----- ----- ------ ---------           austin                U        1      5  hme0            austin                U        1      0  hme0
localhost            localhost             UH      25 215051  lo0

Here, we can see there are two network routes available for packets on the primary Ethernet interface hme0: the network and the multicast network. In addition, the loopback interface (lo0) has the local host interface, which is commonly used for troubleshooting and testing. These routes are all IPv4; however, IPv6 routing details are also displayed:

Routing Table: IPv6
Destination/Mask            Gateway                     Flags Ref Use    If
--------------------------- --------------------------- ----- --- ------ -----
fe80::/10                   fe80::203:baff:fe04:a4e8    U       1      0 hme0
ff00::/8                    fe80::203:baff:fe04:a4e8    U       1      0 hme0
default                     fe80::203:baff:fe04:a4e8    U       1      0 hme0
localhost                   localhost                   UH      5     28 lo0

STREAMS Statistics

STREAMS is a System V package that provides access to system calls, standard libraries, and the kernel for the purposes of writing network applications. Any application that uses STREAMS has a specific set of properties about which statistics can be collected, since the I/O operations are distinct from other networking APIs (such as the BSD-style socket API). netstat  reports these statistics, including queues, which comprise the read/write operations that characterize a stream:

$ netstat -m
streams allocation:
                                         cumulative  allocation
                      current   maximum       total    failures
streams                   326       340        7634           0
queues                    938       962       18662           0
mblk                     1144      1651        7773           0
dblk                     1140      1729     2349590           0
linkblk                    11       169          18           0
strevent                    9       169      121739           0
syncq                      25        50         101           0
qband                       0         0           0           0
1646 Kbytes allocated for streams data

More details can be obtained by reading the manpage for streamio.

IP Interface Statistics

netstat  also reports statistics obtained at the IP level. This includes the number of input and output packets counted, the number of input and output errors, and the number of packet collisions. Again, separate entries are shown for IPv4 and IPv6:

$ netstat -i
Name  Mtu  Net/Dest      Address        Ipkts  Ierrs Opkts  Oerrs Collis Queue
lo0   8232 loopback      localhost      227695 0     227695 0     0      0
hme0  1500 austin        austin         2573   0     2130   0     0      0
Name  Mtu  Net/Dest      Address         Ipkts  Ierrs Opkts  Oerrs Collis
lo0   8252 localhost     localhost       227705 0     227705 0     0
hme0  1500 fe80::203:baff:fe04:a4e8/10 fe80::203:baff:fe04:a4e8    2573   0
2130   0     0

Combined Socket, Route, and Interface Statistics

Most administrators prefer to combine the information that netstat  provides into a single report-style format. This can be achieved by using the combined route, socket, and interface statistics, as shown in the output in Example 4-1.

Example 4-1: Output of the netstat-a command

$ netstat -a
   Local Address         Remote Address     State
-------------------- -------------------- -------
      *.route                               Idle
      *.*                                   Unbound
      *.*                                   Unbound
      *.sunrpc                              Idle
      *.*                                   Unbound
      *.32771                               Idle
      *.sunrpc                              Idle
      *.*                                   Unbound
      *.32775                               Idle
      *.32779                               Idle
      *.32780                               Idle
*.*                                   Unbound
      *.32821                               Idle
      *.32822                               Idle
      *.32823                               Idle
      *.name                                Idle
      *.biff                                Idle
      *.talk                                Idle
      *.time                                Idle
      *.echo                                Idle
   Local Address                     Remote Address                   State
--------------------------------- --------------------------------- ---------- -
      *.*                                                           Unbound
      *.sunrpc                                                      Idle
      *.*                                                           Unbound
      *.32771                                                       Idle
      *.32779                                                       Idle
      *.*                                                           Unbound
      *.32821                                                       Idle
      *.time                                                        Idle
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q  State
-------------------- -------------------- ----- ------ ----- ------ -------
      *.*                  *.*                0      0 24576      0 IDLE
      *.sunrpc             *.*                0      0 24576      0 LISTEN
      *.*                  *.*                0      0 24576      0 IDLE
      *.sunrpc             *.*                0      0 24576      0 LISTEN
      *.*                  *.*                0      0 24576      0 IDLE
      *.32775              *.*                0      0 24576      0 LISTEN
      *.32776              *.*                0      0 24576      0 LISTEN
      *.32782              *.*                0      0 24576      0 LISTEN
      *.32783              *.*                0      0 24576      0 LISTEN
Local Address   Remote Address  Swind  Send-Q  Rwind  Recv-Q  State  If
*.*             *.*             0              24576  0       IDLE
*.sunrpc        *.*             0      0       24576  0       LISTEN
*.*             *.*             0      0       24576  0       IDLE
*.32775         *.*             0      0       24576  0       LISTEN
localhost.32780 localhost.32775 32768  0       32768  0       CLOSE_WAIT
*.32782         *.*             0      0       24576  0       LISTEN
*.32791         *.*             0      0       24576  0       LISTEN
*.ftp           *.*             0      0       24576  0       LISTEN
*.telnet        *.*             0      0       24576  0       LISTEN
Active UNIX domain sockets
Address  Type          Vnode     Conn  Local Addr      Remote Addr
30000d03738 stream-ord 30000d1eb78 00000000 /tmp/.X11-unix/X0
30000d038e0 stream-ord 00000000 00000000
30000d03a88 stream-ord 30000ce4a30 00000000 /tmp/jd_sockV6
30000d03c30 stream-ord 30000a62d78 00000000 /dev/kkcv
30000d03dd8 stream-ord 30000a62f50 00000000 /dev/ccv

Some of the TCP messages shown in this output, for both IPv4 and IPv6, may be unfamiliar, so we review each of them individually:




Socket is bound.


Socket is closed.


Socket is closing.


Socket is waiting to close.


Socket has connected successfully.


Socket is closing (local).


Socket is closing (remote).


Socket is idle.


Socket will close after receiving last acknowledgment.


Socket is active and listening.


Socket is being synchronized.


Socket is creating a connection.


Socket is waiting to close.


Imagine that you are a courier, and your run always starts at the local courier depot. You're given a list of addresses, which are associated with a set of packages, and your goal is to deliver them in as little time as possible, subject to the following constraints:

If this seems like a fairly trivial task for a courier, consider how much more difficult the job would be if the following conditions prevailed:

This scenario describes the difficulties faced by the emergence of the Internet and the massive interconnections between hosts and networks. In order for a packet of data to be transferred from host A to host B, a physical path must be identified for the packet to travel.

There is no central lookup service that decides how to route each packet between all possible combinations of two hosts on the Internet (i.e., between the sender and the receiver). This means routes must be generated dynamically. (The only exceptions to this rule are certain situations where a predictable static route may be installed.)

When transferring data around the Internet or between subnets, intermediate hosts must be responsible for transferring packets between networks; these hosts are called routers and are responsible for routing packets between hosts, which can be separated by single subnets or by entire continents.

Often more then a dozen routers are involved in transfer packets between the sender and the receiver. In addition, the observed response times can be quite slow. It is possible for attempted connections to time out. This can be very useful when trying to identify which intermediate host and/or network is having problems when your remote connection to a host half a world away suddenly dies!

Static routing typically involves creating a direct physical connection between two hosts, where the implementation of dynamic routing would be wasteful or a security risk. For example, if your local network has three subnets that need to share data, a static route could be created between each router and the other two routers in the network. The number of specific routes required to allow data to flow seamlessly between networks is directly proportional to the square of the number of routers on the network. Every time a change is made to the network topology, these routes will have to be modified manually. If that sounds like too much hard work, consider the situation where it might be desirable: a secure database server that can be accessible only by knowing the route to the host and is not publicly announced. Instead of permitting route discovery, a static route is an appropriate technique here. This could be implemented by creating a point-to-point configuration using ifconfig  on a secondary interface, as discussed in the network interface configuration section.

The alternative to static routing is dynamic routing, which involves two daemons: the routing daemon proper (in.routed) and the route discovery daemon (in.rdisc). The in.routed  daemon implements the Routing Information Protocol, and is responsible for updating and managing entries in the kernel's routing tables. It uses UDP (port 520) for performing routing operations and operates on all network interfaces that have been plumbed and are identified as up.

If the /etc/notrouter  file does not exist, and given that two or more operational interfaces can be found, the host begins to act as a router. Data can then be exchanged between data received on one interface, destined to be transmitted from another interface. For a local area network, the interface that connects to all local hosts is usually known as the internal  interface, while the interface that is visible downstream to an ISP or another subnet is known as the external  interface. By using packet filtering, it is possible to specify a set of rules governing what type (TCP or UDP) of packets can be transferred between interfaces and on which ports. This is obviously important for protecting local networks, since services that are available to local hosts may not be appropriate for public access.

The route discovery daemon, in.rdisc, implements the Internet Control Message Protocol (ICMP). In terms of route discovery, in.rdisc  running on host systems listens for multicast broadcasts on the (ALL_HOSTS) address. These messages are prioritized, and the default router is selected based on its proximity to the host. On routers, in.rdisc  broadcasts its availability using multicast on, and listens for requests on (ALL_ROUTERS). Hosts may request a router directly by broadcasting on



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2018 by Dr. Nikolai Bezroukov. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.


FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: September, 12, 2017