This article examines netstat and some of it many outputs, in relation to the open systems interconnect (OSI) model. A quick examination of netstat's man pages provides a description of the program: it prints information about the Linux networking subsystem. But, netstat is not unique to Linux. It also exists in various UNIXes, like HP-UX, and a limited form can be found in Windows 2000. When switches are combined with netstat, a user can print network connections, routing tables, interface statistics, masquerade connections and multicast memberships.

In 1983, the International Organization for Standards (ISO) adopted a Basic Reference Model for Open Systems Interconnection (OSI). The purpose of the model was to provide a basis for coordination of standards development to permit consistent network design.

Figure 1 shows the relationship between the TCP/IP protocol stack and the OSI model.

OSI questions are usually good as icebreakers at job interviews, so I am not going to spend much of this article explaining the OSI model. Pages of notes could be generated discussing the merit of the model and its current relevancy. Personally, I find the model provides guidelines for explaining data communication in a network. I find it useful for establishing a framework on which students can build networking knowledge.

But, many networking students have difficulty finding value in the OSI model because it is virtual and not physical. I have found that networking students like to exist in the physical world; leave the virtual world to the programmers. The netstat command and a few other command friends can be used to bridge the gap between the physical and virtual.

Let's look at some examples to see what netstat can do. Figure 2 shows the different outputs of the netstat command with different switches at virtual layers of the OSI model.

For example, the command netstat combined with the switch -a option produces:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 *:x11                   *:*                     LISTEN
tcp        0      0 *:ftp                   *:*                     LISTEN
tcp        0      0 *:ssh                   *:*                     LISTEN
tcp        0      0 *:telnet                *:*                     LISTEN
tcp        0      0 burner:ssh              prime:1029              ESTABLISHED
tcp        0      0 burner:ssh              prime:1064              ESTABLISHED
udp        0      0 *:tftp                  *:*

The output displays the services available for use on the hosts. In the local address column, it looks like X, FTP, SSH, telnet and TFTP all are available on the host. Supplement the command with a -n switch, and the output is displayed in raw form. The -n switch tells the command to not use host lookup services, DNS, /etc/hosts in producing the output.

Here's another example, netstat -an, which produces:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address                     State
tcp        0      0 0.0.0.0:6000            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN
tcp        0      0 192.168.2.100:22        192.168.2.10:1029       ESTABLISHED
tcp       52      0 192.168.2.100:22        192.168.2.10:1064       ESTABLISHED
udp        0      0 0.0.0.0:69              0.0.0.0:*

The output also displays the status of those services. It looks like two separate connections are being made to burner (192.168.2.100) from prime (192.168.2.10), both using ssh services offered at port 22. The other services are waiting for a connection request. A black hat would be cracking his fingers getting ready for a hack on this system. X (port 6000), FTP (port 21), telnet (port 23) and TFTP (port 60) all have known security weaknesses that can be exploited.

The output displayed from netstat -s provides an indication of what is happening at layers 3 and 4 of the OSI model.

Ip:
    2521652 total packets received
    0 forwarded
    0 incoming packets discarded
    2520742 incoming packets delivered
    2261021 requests sent out

The -r switch produces an output that reflects the OSI network layer. I leave it up to you to discover what the -n option does for the command.

netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.2.0     0.0.0.0         255.255.255.0   U        40 0          0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U        40 0          0 lo
0.0.0.0         192.168.2.1     0.0.0.0         UG       40 0          0 eth0

The output is identical to the Linux route command. Let's see, IP addresses, netmasks, routing...hmm...all seem to have something to do with the network layer. Hey, Win2K fans, netstat -r is supported here. Try a route -print on the MS box, and see if you recognize the output.

I have parsed the text output for the next command only to show the IP protocol. The command output displays the input and output statics of protocols at the network and transport layers. A full display shows statics on TCP, UDP and ICMP protocols.

The -i option provides an output for the lower two layers in the OSI model layers 2 and 1.

netstat -i

produces

Kernel Interface table
Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR   TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0   1500   0 2532677      0      0      0 2261129      0      0      0 BMRU
lo    16436   0     295      0      0      0     295      0      0      0 LRU

Physical interfaces exist at layer 1. The output displays an eth0 and lo interfaces. The output provides statics on the performance of the interface. Sorry, MS Windows 2000 clients, this option is not supported in your release.

The OSI model discusses general data communication functions; it does not specify how to implement the functions. The model describes what functions are performed at each layer. The model is somewhat difficult to comprehend because it does not exist in a physical world. Network people live in a physical world of NIC cards, cables and network elements. The netstat command output, though, bridges the gap between the virtual and physical. Asking a network person to explain a programming socket is like asking an individual to go stand in the corner of a round room. In other words, it is easier for a networking person to see the concept of a socket using the output of a netstat -an command.