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.
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.
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.
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 203.54.68.21, while a web client (such as Netscape Navigator) runs on the host 203.54.67.122. 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 203.54.67.122 to the server 203.54.68.21, 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.
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="http://data.cassowary.net/servlet/StockServer?code=SUNW"; URL u = new URL(stockURL); BufferedReader in = new BufferedReader(new InputStreamReader(u.openStream())); String stockPrice=in.readLine(); in.close();
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: http://www.xmltoday.com/examples/stockquote/getxmlquote.vep?s=SUNW
The data returned from this request can be parsed, and its tags can be interpreted by a client program:
<stock_quotes>
<stock_quote>
<symbol>>SUNW<</symbol>
<when>
<date>10/30/2002</date>
<time>3:06pm</time>
</when>>
<price type="ask" value="2.50" />
<price type="open" value="2.60" />
<price type="dayhigh" value="2.60" />
<price type="daylow" value="2.49" />
<change>-0.10</change>
<volume>5768644</volume>
</stock_quote>
</stock_quotes>
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.
Figure 32-5: The Open System Interconnect (OSI) networking model.
| Tip |
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: 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) ETHER: IP: ----- IP Header ----- IP: 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 = 64.23.168.76, moppet.paulwatters.com IP: Destination address = 64.23.168.48, miki.paulwatters.com IP: No options IP: TCP: ----- TCP Header ----- TCP: 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 TCP: TELNET: ----- TELNET: ----- TELNET: TELNET: "a" TELNET:
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.
| Tip |
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.
| EXAM TIP |
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.
| Caution |
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 www.cassowary.net 255.255.255.255 00:19:cd:e3:05:a3 hme0 mail.cassowary.net 255.255.255.255 08:11:92:a4:12:ee hme0 ftp.cassowary.net 255.255.255.255 SP 08:12:4e:4d:55:a2 hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 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 (204.67.34.12) 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.
| Tip |
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.
IPv4
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 192.205.76.123, 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 0.0.0.0–127.255.255.255
-
Class B 128.0.0.0–191.255.255.255
-
Class C 192.0.0.0–223.255.255.255
-
Class D 224.0.0.0–239.255.255.255
-
Class E 240.0.0.0–247.255.255.255
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 10.0.0.0 is reserved for private use and is commonly used to define IP address for internal networks. This is a security feature, because 10.0.0.0 addresses are not resolvable from the Internet. In addition, the 127.0.0.0 addresses are used to refer to the localhost, with the most commonly used value being 127.0.0.1.
Subnets allow large networks to be divided up into smaller logical networks by using a subnet mask. For Class A networks, the mask is 255.0.0.0; for Class B networks, the mask is 255.255.0.0; and for Class C networks, the mask is 255.255.255.0.
| Tip |
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
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 (http://www.rfc-editor.org/rfc.html). 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 users.cassowary.net, the following command would be used:
$ talk shusaku@users.cassowary.net
If the host users.cassowary.net is running inetd, and inetd supports in.talkd, the following talk request would appear on the user shusaku’s login shell:
Message from Talk_Daemon@db.cassowary.net at 10:50 ... talk: connection requested by yasuanri@db.cassowary.net. talk: respond with: talk yasunari@db.cassowary.net
If the user shusaku wished to “talk” with yasunari, the following command would be used by shusaku:
$ talk yasunari@db.cassowary.net
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.
