Network Concepts

Network Concepts

A network is a combination of hardware and software that enables computers to communicate with each other. At the hardware level, building a network involves installing a network interface into each system (“host”) to be networked and implementing a specific network topology by using cables, such as Ethernet or wireless. At the software level, representations of network devices must be created and protocols for exchanging data between hosts must be established. Data is exchanged by dividing it into packets that have a specific structure, enabling large data elements to be exchanged between hosts by using a small amount of wrapping. This wrapping, based on various protocols, contains information about the order in which packets should be assembled when transmitted from one host to another, for example.

By supporting many different types of hardware devices and connection technologies, and by implementing standards-based networking software, Solaris provides a flexible platform for supporting high-level network services and applications. These will be explored in detail in the following chapters.

Network Topologies

The two most common forms of network topology are the star network and the ring network. The ring topology, as shown in Figure 32-1, is a peer-to-peer topology where neighboring hosts are connected and data is exchanged between distant hosts by passing data from the source host to the target host through all intermediate hosts. Ring networks are most suitable for networks where long distances separate individual hosts. However, if only one of the links between hosts is broken, then data transmission between all hosts can be interrupted.

Click To expand Figure 32-1: Ring network topology.

In contrast, a star network has a centralized topology, where all hosts connect to a central point and exchange data at that point, as shown in Figure 32-2. This has the advantage of minimizing the number of hops that data must travel from a source to a target host, compared to a ring network. In addition, if one link is broken, only data originating from or sent to the host on that link will be disrupted. However, if the point at which hosts are connected breaks down, then all data transmission will cease.

Click To expand
Figure 32-2: Star network topology.

In practice, most modern high-speed networks are based on star topologies. When connecting local area networks together to form internets, a star topology has the advantage of being able to interconnect networks by their central connection points. This means that data sent from a host on one network must travel to its central point, which then sends the data to the connection point on a remote network, which then passes the data to the remote target host. Thus, only three hops are required to exchange data between hosts on two networks when using a star topology. This data flow is shown in Figure 32-3.

Click To expand
Figure 32-3: Interconnecting networks.

Let’s look at a specific example of how an internet can be laid out before examining how OSI and the Solaris implementation of TCP/IP make this possible. Imagine that a web server runs on the host, while a web client (such as Netscape Navigator) runs on the host Because these two hosts are located on two different local area (Class C) networks, they must be interconnected by a router. In the star topology, a connection point must allow a link to each host on the local network—in this example, a hub is used to connect each host, as well as forwarding all data bound for nonlocal addresses to the router. Thus, when a high-level HTTP request is sent from the client to the server, a packet is sent to the hub, which detects that the destination is nonlocal and forwards the packet to the router. The router then forwards the packet to the router for the remote network, which detects that the destination is local and passes it to the hub, which in turn passes it to the server. Because HTTP is a request/response protocol, the backwards path is traced when a response to the request is generated by the server. The configuration for this example is shown in Figure 32-4.

Click To expand
Figure 32-4: Supporting high-level services.

If this example seems complex, you’ll be pleased to know that the implementation of many of these services is hidden from users, and most often from developers. This makes implementing networking applications very simple when using high-level protocols like HTTP. For example, consider the following Java code, which uses HTTP to make a connection to a remote server running an application called StockServer. After passing the name of a stock in the URL, the current price should be returned by the server. The code fragment shows the definition for the URL, and a declaration for an input stream, which reads a line from the stream and assigns the result to a variable (stockPrice), and then closes the stream. If this code was contained in an applet, for example, the stockPrice for SUNW could then be displayed.

String stockURL="";
URL u = new URL(stockURL);
BufferedReader in = new BufferedReader(new InputStreamReader(u.openStream()));
String stockPrice=in.readLine();

A further level of abstraction is provided by Web Services and the Simple Object Access Protocol (SOAP), which uses HTTP as a transport for transmitting requests to execute Remote Procedure Calls (RPC) in a platform-independent way. This approach has some similarities to working directly at the HTTP level, because a URL can be used to execute the SOAP request but the data is returned in a standard XML format. The following URL, for example, is used to retrieve the stock price for Sun Microsystems from XML Today:

The data returned from this request can be parsed, and its tags can be interpreted by a client program:

            <price type="ask" value="2.50" />
            <price type="open" value="2.60" />
            <price type="dayhigh" value="2.60" />
            <price type="daylow" value="2.49" />

Web Services will become more commonly used in future versions of Solaris and related enterprise applications, so it’s useful to understand how they work and how they relate to underlying networking protocols.

Open System Interconnect (OSI) Networking

Building networks is complex, given the wide array of hardware and software that can be used to implement them. The OSI networking model, as shown in Figure 32-5, provides a framework for defining the scope of different layers of networking technology, which can be used to understand how different protocols and suites (such as TCP/IP) operate. Each layer of the model, starting from the bottom, supports the functionality required by the top levels. Moving from bottom to top, operations become more and more abstracted from their physical implementation. It is this abstraction that allows HTTP and other high-level protocols to operate without being concerned about low-level implementations.

Click To expand
Figure 32-5: The Open System Interconnect (OSI) networking model.

The OSI networking model allows for different instantiations of lower levels, without higher-level code needing to be rewritten.

Starting from the bottom, the first level is the Physical Layer, which defines both how data is exchanged at its very basic level (bits and bytes) and cabling requirements. The second level is the Data Link Layer, which defines the apparatus for transferring data, including error checking and synchronization. The third level is the Network Layer, which specifies operational issues such as how networks can exchange data, as shown in Figures 32-3 and 32-4. The fourth level is the Transport Layer, which specifies how individual computers are to interpret data received from the network. The fifth level is the Session Layer, which determines how data from different sources can be separated, and how associations between hosts can be maintained. The sixth level is the Presentation Layer, which specifies how different types of data are formatted and how it should be exposed. The seventh level is the Application Layer, which describes how high-level applications can communicate with each other in a standard way.

TCP/IP Networking

The TCP/IP suite of protocols forms the basis of all Internet communications and was originally devised as part of the Defense Advanced Research Projects Agency (DARPA) for the ARPANET. While TCP/IP is the default networking protocol supported by Solaris, other operating systems also support TCP/IP, even if it is not their primary protocol. For example, Microsoft Windows networks support NetBEUI and IPX/SPX, while MacOS supports AppleTalk. Linux administrators should already be familiar with TCP/IP because, like Solaris, it is the default networking protocol.

TCP/IP presents a simpler interface than OSI, since only the Application, Transport, Network and Link layers need to be addressed. This can be seen in the following packet intercept performed by the snoop application, which reads raw packet data from a network interface operating in promiscuous mode. The following example shows ETHER (Link), IP (Network), TCP (Transport), and TELNET (Application) sections respectively:

# snoop -v tcp port 23
Using device /dev/hme0 (promiscuous mode)
ETHER:  ----- Ether Header -----
ETHER:  Packet 1 arrived at 14:13:22.14
ETHER:  Packet size = 60 bytes
ETHER:  Destination = 1:58:4:16:8a:34,
ETHER:  Source      = 2:60:5:12:6b:35, Sun
ETHER:  Ethertype = 0800 (IP)
IP:   ----- IP Header -----
IP:   Version = 4
IP:   Header length = 20 bytes
IP:   Type of service = 0x00
IP:         xxx. .... = 0 (precedence)
IP:         ...0 .... = normal delay
IP:         ..... = normal throughput
IP:         .... .0.. = normal reliability
IP:   Total length = 40 bytes
IP:   Identification = 46864
IP:   Flags = 0x4
IP:         .1.. .... = do not fragment
IP:         ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 255 seconds/hops
IP:   Protocol = 6 (TCP)
IP:   Header checksum = 11a9
IP:   Source address =,
IP:   Destination address =,
IP:   No options
TCP:  ----- TCP Header -----
TCP:  Source port = 62421
TCP:  Destination port = 23 (TELNET)
TCP:  Sequence number = 796159562
TCP:  Acknowledgement number = 105859685
TCP:  Data offset = 20 bytes
TCP:  Flags = 0x10
TCP:        ..0. .... = No urgent pointer
TCP:        ...1 .... = Acknowledgement
TCP:        ..... = No push
TCP:        .... .0.. = No reset
TCP:        .... ..0. = No Syn
TCP:        .... ...0 = No Fin
TCP:  Window = 8760
TCP:  Checksum = 0x8f8f
TCP:  Urgent pointer = 0
TCP:  No options
TELNET:  ----- TELNET:   -----
TELNET:  "a"

TCP/IP is layered, just like the OSI reference model. Thus, when a client application needs to communicate with a server, a process is initiated of passing data down each level on the client side, from the Application Layer to the Physical Layer, and up each level on the server side, from the Physical Layer to the Application Layer. Data is passed between layers in service data units. However, it’s important to note that each client layer logically only ever communicates with the corresponding server layer, as demonstrated by the Java code presented previously: the Application Layer is not concerned with logically communicating with the Physical Layer, for example.


Abstraction is the core benefit of TCP/IP in development and communication terms, since each level is logically isolated, while methods for supporting service data are also well defined.

Exercise 32-1 Running snoop  As root, run the snoop command and examine the headers for each network layer.

The ETHER header defines many of the characteristics of the packet. In the snoop example, the packets arrival time, size (in bytes), destination, and source addresses (Ethernet format) are all noted. In addition, the network type is supplied. This leads into the IP header, which shows the IP version (IPv4), the length of the header (in bytes), destination and source addresses (IP format), and a checksum to ensure data integrity. Also, the protocol for transport is defined as TCP. The TCP header shows the port on which the data is being sent and on which it should be received, in addition to the application type (TELNET). The sequence and acknowledgement numbers determine how packets are ordered at the receiving end, because TCP is connection-oriented and guarantees data delivery, unlike other transport protocols (for example, UDP) that are connectionless and do not guarantee the delivery of data. Finally, the data being transported is displayed: “a”. In addition to TELNET, other application protocols include the Simple Mail Transfer Protocol (SMTP), the File Transfer Protocol (FTP), and the Network File System (NFS).

We’ll now review each of these layers as they are implemented in the Solaris TCP/IP stack.


You should be able to relate definitions of different OSI layer functionality to specific layer names.

Ethernet Layer

Ethernet is the most commonly used link technology supported by Solaris and comes in five different speeds, including:

  • 10Base-2 2 Mbps

  • 10Base-5 5 Mbps

  • 10Base-T 10 Mbps

  • 100Base-T 100 Mbps

  • 1000Base-FX 1Gbps

Solaris systems are typically supplied with a single Ethernet card, supporting 10/100 Mbps; however, server systems (such as the 420R) are supplied with quad Ethernet cards, supporting four interfaces operating at 10/100 Mbps. Although Ethernet (specified by the IEEE 802.3 standard) is the most common link type, other supported link types on Solaris include the Fiber Distributed Data Interface (FDDI) and Asynchronous Transfer Mode (ATM). FDDI networks use a ring topology based on a transmitting and receiving ring, using high-quality fiber-optic cable to support high-speed redundant connections. However, FDDI is expensive compared to Ethernet, and gigabit FDDI is not available. ATM is designed for high quality of service applications, like video and audio streaming, which require a constant amount of bandwidth to operate. Data is transmitted in fixed-size cells of 53 bytes, and a connection is maintained while required between client and server.


Although ATM does not approach the speeds of Gigabit Ethernet, its quality of service provisions benefit certain types of data transmission.

Note that the address used in the ETHER is the hardware address, otherwise known as the Media Access Control (MAC) address. This address is used to distinguish hosts at the link level and is mapped to an IP address at the network level by using the Address Resolution Protocol (ARP). You can check the table of IP address to MAC address mappings by using the arp command:

$ arp –a
Net to Media Table
Device IP Address              Mask            Flags Phys Addr
------ ---------------------- --------------- ----- ---------------
hme0       00:19:cd:e3:05:a3
hme0       08:11:92:a4:12:ee
hme0 SP    08:12:4e:4d:55:a2
hme0   BASE-ADDRESS.MCAST.NET       SM    01:01:4e:00:00:00

Here, the network device is shown with either the fully qualified hostname or IP address, the netmask, any flags, and the MAC address. The flags indicate the status of each interface, including “SP” for the localhost, where an entry will be published on request, and “SM” for the localhost, supporting multicast. Alternatively, a specific host can be queries by passing its name on the command line:

$ arp mail
mail ( at 08:11:92:a4:12:ee

Conversely, the Reverse Address Resolution Protocol (RARP) is used to map MAC addresses to IP addresses. RARP is typically used to supply IP addresses from boot servers to diskless clients.


A database of Ethernet addresses is maintained in the /etc/ethers table to support this activity.

Exercise 32-2 Running arp  Run arp –a on your local system. Are there any flags displayed that are not described here? If so, read the man page for arp and interpret them.


The basic element of the Internet Protocol version (IPv4) is the IP address, which is a 32-bit number (4 bytes) that uniquely identifies network interfaces on the Internet. For “single-homed” hosts, which have only one network interface, the IP address identifies the host. However, for “multihomed” hosts, which have multiple network interfaces, the IP address does not uniquely identify the host. Even the domain name assigned to a multihost can be different, depending on which network the interface is connected to. For example, a router, as a host that contains at least two interfaces, supports the passing of data between networks.

The IP address is usually specified in dot decimal notation, in which each of the bytes is displayed as an integer separated by a “dot.” An example IP address is, which is based on a Class C network. There are five “classes” of networks defined by IP (A, B, C, D, E), although only three of these (A, B, C) are actually used for the identification of hosts. Network classes can be identified by a discrete range of values; thus, if an address lies within a specific range, it can be identified as belonging to a network of a specific class. The following ranges are defined by IP:

  • Class A–

  • Class B–

  • Class C–

  • Class D–

  • Class E–

The different classes allow for ever-decreasing numbers of hosts in each network, starting from Class A, where networks can support millions of hosts, to Class C networks, which can only support up to 254 hosts. Some address ranges have special purposes: the network is reserved for private use and is commonly used to define IP address for internal networks. This is a security feature, because addresses are not resolvable from the Internet. In addition, the addresses are used to refer to the localhost, with the most commonly used value being

Subnets allow large networks to be divided up into smaller logical networks by using a subnet mask. For Class A networks, the mask is; for Class B networks, the mask is; and for Class C networks, the mask is


Solaris 9 now provides complete support for IPv6 and IPSec, discussed in Chapter 36. These innovations are designed to increase the capacity of the Internet, and secure packets transmitted by using transport protocols.


TCP is a connection-oriented protocol that guarantees delivery of packets, where data has been segmented into smaller units. The benefit of transmitting small units in a guaranteed delivery scheme is that if checksum errors are detected or some data is not received, the amount of data that needs to be retransmitted is very small. In addition, if packet delivery “times out,” packets can then be retransmitted. By using sequence numbers, TCP always manages to reassemble packets in their correct order. Port numbers for TCP (and UDP) services are defined in the /etc/services database. A sample database is shown here:

tcpmux          1/tcp
echo            7/tcp
echo            7/udp
discard         9/tcp           sink null
discard         9/udp           sink null
systat          11/tcp          users
daytime         13/tcp
daytime         13/udp
netstat         15/tcp
chargen         19/tcp          ttytst source
chargen         19/udp          ttytst source
ftp-data        20/tcp
ftp             21/tcp
telnet          23/tcp
smtp            25/tcp          mail
time            37/tcp          timserver
time            37/udp          timserver
name            42/udp          nameserver
whois           43/tcp          nickname
domain          53/udp
domain          53/tcp
bootps          67/udp
bootpc          68/udp
hostnames       101/tcp         hostname
pop2            109/tcp         pop-2
pop3            110/tcp
sunrpc          111/udp         rpcbind
sunrpc          111/tcp         rpcbind
imap            143/tcp         imap2
ldap            389/tcp
ldap            389/udp
ldaps           636/tcp
ldaps           636/udp
tftp            69/udp
rje             77/tcp
finger          79/tcp
link            87/tcp          ttylink
supdup          95/tcp

Reading from left to right is the service name, port number transport type, and service aliases. For example, the sunrpc service is also known as rpcbind and is essential for supporting Remote Procedure Call (RPC) applications like NFS. Other services defined previously include the echo service, which simply sends back the segment transmitted to it; daytime, which returns the current local time at the server; ftp, which supports the File Transfer Protocol (FTP) service; and smtp, which supports the Simple Mail Transfer Protocol (SMTP). If services are not to be supported on the localhost, their entries should be commented in the service database. For example, to disable the service definition for the finger service, which allows remote users to check local user details, the finger entry would be modified as follows:

#finger          79/tcp

Port numbers between 1 and 1024 are standard, as defined by Request For Comment (RFC) memos ( Nonstandard services can be run on ports above 1024.

Application Protocols

Services are implemented by daemons that listen for connections and generate responses based on specific requests. Many of the TCP service definitions match up with an application supported by a daemon (server) process. There are two types of daemons supported by Solaris: stand-alone daemons and inetd daemons. Stand-alone daemons internally manage their own activities, while inetd allows daemons to be run through a single central server. This allows for centralization of administration and reduced need for processes running on a system, because inetd can listen for connections and invoke daemon processes as required. Definitions for services are contained in the /etc/inetd.conf file. A sample /etc/inetd.conf file is shown here:

ftp     stream  tcp     nowait  root    /usr/sbin/in.ftpd       in.ftpd -l
telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd    in.telnetd
name    dgram   udp     wait    root    /usr/sbin/in.tnamed     in.tnamed
shell   stream  tcp     nowait  root    /usr/sbin/in.rshd       in.rshd
login   stream  tcp     nowait  root    /usr/sbin/in.rlogind    in.rlogind
exec    stream  tcp     nowait  root    /usr/sbin/in.rexecd     in.rexecd
comsat  dgram   udp     wait    root    /usr/sbin/in.comsat     in.comsat
talk    dgram   udp     wait    root    /usr/sbin/in.talkd      in.talkd
uucp    stream  tcp     nowait  root    /usr/sbin/in.uucpd      in.uucpd
tftp    dgram   udp     wait    root    /usr/sbin/in.tftpd      in.tftpd
 -s /tftpboot
finger  stream  tcp     nowait  nobody  /usr/sbin/in.fingerd    in.fingerd
systat  stream  tcp     nowait  root    /usr/bin/ps             ps -ef
netstat stream  tcp     nowait  root    /usr/bin/netstat        netstat -f inet
time    stream  tcp     nowait  root    internal
time    dgram   udp     wait    root    internal
echo    stream  tcp     nowait  root    internal
echo    dgram   udp     wait    root    internal
discard stream  tcp     nowait  root    internal
discard dgram   udp     wait    root    internal
daytime stream  tcp     nowait  root    internal
daytime dgram   udp     wait    root    internal
chargen stream  tcp     nowait  root    internal
chargen dgram   udp     wait    root    internal

Reading from left to right are the service name, socket type, transport protocol, flags, executing user, and daemon program to execute upon request. Socket types include streams or datagrams, transports include TCP and UDP, and flags include wait (wait after response) and nowait (exit after response).

A sample inetd application is the talk service. By examining its definition in /etc/inetd.conf, we can see that it uses datagram sockets, runs on UDP, waits until timeout, is run by root, is implemented by the command /usr/sbin/in.talkd, and has the name in.talkd. The talk service supports instant communications between users on the local system, or between any two systems on the Internet. To issue a talk request to a remote user, a local user would issue the talk command followed by the user’s username and fully qualified domain name. For example, to talk to the user shusaku at the host, the following command would be used:

$ talk

If the host is running inetd, and inetd supports in.talkd, the following talk request would appear on the user shusaku’s login shell:

Message from at 10:50 ...
talk: connection requested by
talk: respond with:  talk

If the user shusaku wished to “talk” with yasunari, the following command would be used by shusaku:

$ talk

If a service is to be disabled for security purposes, then its entry can simply be commented out, just like for the services database. For example, to disable the finger service, the finger entry would be commented as follows:

#finger  stream  tcp     nowait  nobody  /usr/sbin/in.fingerd    in.fingerd

Once changes have been made to inetd.conf, a SIGHUP signal should be sent to the inetd process, causing it to reread the inetd.conf file. To restart inetd with a PID of 186, the following command would be used:

# kill –1 186

Many of the services supported by inetd support remote access and can possibly be deemed security risks.

Part I: Solaris 9 Operating Environment, Exam I