Part I Setting Up and Administering TCP/IP Networks

Part 1 explains how to set up a network that will run the Solaris implementation of TCP/IP. The text assumes that you are familiar with UNIX and have some experience administering local UNIX systems. It does not assume that you are an experienced network administrator.

• "Responsibilities of the Network Administrator"

• "Types of Hardware That Make Up a Solaris Network"

• "Introducing the Internet Protocol Suite"

• "Designing Your IP Addressing Scheme"

• "Selecting a Name Service"

• "Determining Host Configuration Modes"

• "TCP/IP Configuration Files"

• "Network Configuration Procedures"

• "Routing Protocols"

• "Configuring Routers"

• "General Troubleshooting Methods"

• "Running Software Checks"

Chapter 1 Overview of Network Administration

This chapter introduces the role of the network administrator. If you are a new network administrator, the topics covered give you an idea of the tasks you might perform. The chapter then presents fundamental networking concepts that you need to know as you progress through this book. If you are an experienced network administrator, consider skipping this chapter.

• "Designing the Network"

• "Maintaining the Network"

• "Expanding the Network"

• "What is TCP/IP?"

• "Types of Hardware That Make Up a Solaris Network"

• "How Information Is Transferred: The Packet"

• "Who Sends and Receives Information: The Host"

Responsibilities of the Network Administrator

As a network administrator, your tasks generally fall into four areas:

• Designing and planning the network

• Setting up the network

• Maintaining the network

• Expanding the network

Each task area corresponds to a phase in the continuing life cycle of a network. You may be responsible for all the phases, or you may ultimately specialize in a particular area; for example, network maintenance.

Designing the Network

The first phase in the life cycle of a network involves creating its design, a task not usually performed by new network administrators. Designing a network involves making decisions about the type of network that best suits the needs of your organization. In larger sites this task is performed by a senior network architect: an experienced network administrator familiar with both network software and hardware.

Chapter 3, Planning Your Network, describes the factors involved in network design.

Setting Up the Network

After the new network is designed, the second phase of network administration begins, which involves setting up and configuring the network. This consists of installing the hardware that makes up the physical part of the network, and configuring the files or databases, hosts, routers, and network configuration servers.

The tasks involved in this phase are a major responsibility for network administrators. You should expect to perform these tasks unless your organization is very large, with an adequate network structure already in place.

Chapter 4, Configuring TCP/IP on the Network, contains instructions for the tasks involved in this phase of the network life cycle.

Maintaining the Network

The third phase of network administration consists of ongoing tasks that typically constitute the bulk of your responsibilities. They might include:

• Adding new host machines to the network

• Network security

• Administering network services, such as NFS\256, name services, and electronic mail

• Troubleshooting network problems

Chapter 4, Configuring TCP/IP on the Network, explains how to set up new hosts on an existing network. Chapter 6, Troubleshooting TCP/IP, contains hints for solving network problems. For information on network services, refer to the NFS Administration Guide, the Solaris Naming Administration Guide, the NIS+ Transition Guide, and the Mail Administration Guide. For security-related tasks, refer to the System Administration Guide.

Expanding the Network

The longer a network is in place and functioning properly, the more your organization might want to expand its features and services. Initially, you can increase network population by adding new hosts and expanding network services by providing additional shared software. But eventually, a single network will expand to the point where it can no longer operate efficiently. That is when it must enter the fourth phase of the network administration cycle: expansion.

Several options are available for expanding your network:

• Setting up a new network and connecting it to the existing network using a machine functioning as a router, thus creating an internetwork

• Configuring machines in users' homes or in remote office sites and enabling these machines to connect over telephone lines to your network

• Connecting your network to the Internet, thus enabling users on your network to retrieve information from other systems throughout the world

• Configuring UUCP communications, enabling users to exchange files and electronic mail with remote machines

Chapter 5, Configuring Routers, contains procedures for setting up an internetwork. Part II, explains how to set up networking connections for nomadic computers. Part III, explains how to use UUCP to exchange information between your machine and other UUCP systems.

What is TCP/IP?

A network communications protocol is a set of formal rules that describe how software and hardware should interact within a network. For the network to function properly, information must be delivered to the intended destination in an intelligible form. Because different types of networking software and hardware need to interact to perform the network function, designers developed the concept of the communications protocol.

The Solaris operating system includes the software needed for network operations for your organization. This networking software implements the communications protocol suite, collectively referred to as TCP/IP. TCP/IP is recognized as a standard by major international standards organizations and is used throughout the world. Because it is a set of standards, TCP/IP runs on many different types of computers, making it easy for you to set up a heterogeneous network running the Solaris operating system.

TCP/IP provides services to many different types of computers, operating systems, and networks. Types of networks range from local area networks, such as Ethernet, FDDI, and Token Ring, to wide-area networks, such as T1 (telephone lines), X.25, and ATM.

You can use TCP/IP to construct a network out of a number of local-area networks. You can also use TCP/IP to construct a wide-area network by way of virtually any point-to-point digital circuit.

TCP/IP and its protocol family are fully described in Chapter 2, TCP/IP Protocol Suite.

Types of Hardware That Make Up a Solaris Network

The term local-area network (LAN) refers to a single network of computers limited to a moderate geographical range, such as the floor of a building or two adjacent buildings. A local-area network has both hardware and software components. From a hardware perspective, a basic Solaris LAN consists of two or more computers attached to some form of local-area network media.

Local-Area Network Media

The cabling or wiring used for computer networks is referred to as network media. Figure 1-1 shows four computers connected by means of Ethernet media. In the Solaris LAN environment, Ethernet is the most commonly used local-area network media. Other types of local-area network media used in a Solaris LAN might include FDDI or Token Ring.

Figure 1-1 A Solaris Local Area Network

Computers and Their Connectors

Computers on a TCP/IP network use two different kinds of connectors to connect to network media: serial ports, and the ports on the network interface.

Serial Ports

Each computer has at least two serial ports, the connectors that enable you to plug a printer or modem into the computer. The serial ports may be attached to the CPU board, or you may have to purchase them. You use these ports when attaching a modem to the system to establish a PPP or UUCP connection. PPP and UUCP actually provide wide-area network services, since they may use telephone lines as their network media.

Network Interfaces

The hardware in a computer that enables you to connect it to a network is known as a network interface. Many computers come with a preinstalled network interface; others may require you to purchase the network interface separately.

Each LAN media type has its own associated network interface. For example, if you want to use Ethernet as your network media, you must have an Ethernet interface installed in each host to be part of the network. The connectors on the board to which you attach the Ethernet cable are referred to as Ethernet ports. If you plan to use FDDI, each prospective host must have an FDDI network interface, and so on.

This book refers to the default network interface on a host as the primary network interface.

Installing network hardware is outside the scope of this guide. Refer to System Administration Guide for instructions for configuring serial ports and manuals accompanying network media for installation instructions.

How Network Software Transfers Information

Setting up network software is an involved task. Therefore, it helps to understand how the network software you are about to set up will transfer information.

Figure 1-2 shows the basic elements involved in network communication.

Figure 1-2 How Information Is Transferred on a Network

In this figure, a computer sends a packet over the network media to another computer attached to the same media.

How Information Is Transferred: The Packet

The basic unit of information to be transferred over the network is referred to as a packet. A packet is organized much like a conventional letter.

Each packet has a header, which corresponds to the envelope. The header contains the addresses of the recipient and the sender, plus information on how to handle the packet as it travels through each layer of the protocol suite.

The message part of the packet corresponds to the letter itself. Packets can only contain a finite number of bytes of data, depending on the network media in use. Therefore, typical communications such as email messages are sometimes split into packet fragments.

Who Sends and Receives Information: The Host

If you are an experienced Solaris user, you are no doubt familiar with the term "host," a word often used as a synonym for "computer" or "machine." From a TCP/IP perspective, only two types of entities exist on a network: routers and hosts.

A router is a machine that forwards packets from one network to another. To do this, the router must have at least two network interfaces. A machine with only one network interface cannot forward packets; it is considered a host. Most of the machines you set up on a network will be hosts.

It is possible for a machine to have more than one network interface but not function as a router. This type of machine is called a multihomed host. A multihomed host is directly connected to multiple networks through its network interfaces. However, it does not route packets from one network to another.

When a host initiates communication, it is called a sending host, or the sender. For example, a host initiates communications when its user types rlogin or sends an email message to another user. The host that is the target of the communication is called the receiving host, or recipient. For example, the remote host specified as the argument to rlogin is the recipient of the request to log in.

Each host has three characteristics that help identify it to its peers on the network. These characteristics include:

• Host name

• Internet address, or IP address, the form used in this book

• Hardware address

Host Name

The host name is the name of the local machine, combined with the name of your organization. Many organizations let users choose the host names for their machines. Programs such as sendmail and rlogin use host names to specify remote machines on a network. System Administration Guide contains more information about host names.

The host name of the machine also becomes the name of the primary network interface. This concept becomes important when you set up the network databases or configure routers.

When setting up a network, you must obtain the host names of all machines to be involved. You will use this information when setting up network databases, as described in Chapter 4, Configuring TCP/IP on the Network.

IP Address

The IP address is one of the two types of addresses each machine has on a TCP/IP network that identifies the machine to its peers on the network. This address also gives peer hosts a notion of where a particular host is located on the network. If you have installed the Solaris operating environment on a machine on a network, you may recall specifying the IP address during the installation process. IP addressing is a significant aspect of TCP/IP and is explained fully in "Designing Your IP Addressing Scheme".

Hardware Address

Each host on a network has a hardware address, which also identifies it to its peers. This address is physically assigned to the machine's CPU or network interface by the manufacturer. Each hardware address is unique.

This book uses the term Ethernet address to correspond to the hardware address. Because Ethernet is the most commonly used network media on Solaris-based networks, the text assumes that the hardware address of your Solaris host is an Ethernet address. If you are using other network media, such as FDDI, refer to the documentation that came with your media for hardware addressing information.

Reaching Beyond the Local-Area Network--the Wide-Area Network

As your network continues to function successfully, users may need to access information available from other companies, institutes of higher learning, and other organizations not on your LAN. To obtain this information, they may need to communicate over a wide-area network (WAN), a network that covers a potentially vast geographic area and uses network media such as leased data or telephone lines, X.25, and ISDN services.

A prime example of a WAN is the Internet, the global public network that is the successor to the WANs for which TCP/IP was originally developed. Other examples of WANs are enterprise networks, linking the separate offices of a single corporation into one network spanning an entire country, or perhaps an entire continent. It is entirely possible for your organization to construct its own WAN.

As network administrator, you may have to provide access to WANs to the users on your local net. Within the TCP/IP and UNIX community, the most commonly used public network has been the Internet. Information about directly connecting to the Internet is outside the scope of this book. You can find many helpful books on this subject in a computer bookstore.

Security

Connecting a LAN to a WAN poses some security risks. You must make sure your network is protected from unauthorized use, and control access to data and resources. An overview of security issues is provided in the System Administration Guide. Further help can be found in Firewalls and Internet Security by William R. Cheswick and Steven M Bellovin (Addison Wesley, 1994).

You can also become informed by subscribing to majordomo@greatcircle.com, citing subscribe firewalls in the text. If you prefer the shorter version, cite firewalls_digest in the text.

TCP Large Window Support

TCP large windows provides the support described in RFC1323. This support is designed to improve performance over large bandwidth or delay networks such as ATM or satellite networks by using windows that exceed the normal 65535 limit.

This support expands the amount of data that can be outstanding in a TCP session from 65,535 bytes to approximately 1 Gigabyte.

TCP large window supports a number of TCP configuration parameters which allow a system administrator to enable the use of enhanced send and receive window sizes and the RFC1323 timestamp option, without having to modify the applications. These changes can be made on a system-wide basis or can be customized for particular hosts or networks. This is especially useful when using standard network utilities such as ftp and rcp which do not provide facilities to increase the buffer sizes they use.

TCP Large Window Parameters

The configuration parameters are associated with the TCP device, /dev/tcp, and may be inspected or modified using ndd(5). Normally, these parameters would be set in one of the shell scripts executed by init(1M) when the system is booted (see init.d(4) for information on how to add a new script).

A list of the available parameters and their meaning are.

tcp_xmit_hiwat

Specifies the default value for a connection's send buffer space. The default is 8K.

tcp_recv_hiwat

Specifies the default value for a connection's receive buffer space; that is, the amount of buffer space allocated for received data (and thus the maximum possible advertised receive window). The default is 8K.

tcp_wscale_always

If this parameter is nonzero, a window scale option is always sent when connecting to a remote system. Otherwise, the option will be sent if-and-only-if the user has requested a receive window larger than 64K. The default is zero.

Regardless of the value of this parameter, a window scale option is always included in a connect acknowledgment if the connecting system has used the option.

tcp_tstamp_always

If this parameter is nonzero, a timestamp option is always sent when connecting to a remote system. The default is zero.

Regardless of the value of this parameter, a timestamp option is always included in a connect acknowledgment (and all succeeding packets) if the connecting system has used the option.

tcp_tstamp_if_wscale

If this parameter is nonzero, the timestamp option is sent when connecting to a remote system if the user has requested a receive window larger than 64K (that is, if a window scale option with a nonzero scale is being used). The default is zero.

tcp_max_buf

Specifies the maximum buffer size a user is allowed to specify with the SO_SNDBUF or SO_RCVBUF options. Attempts to use larger buffers fail with EINVAL. The default is 256K. It is unwise to make this parameter much larger than the maximum buffer size your applications require, since that could allow malfunctioning or malicious applications to consume unreasonable amounts of kernel memory.

tcp_host_param

This parameter is a table of IP addresses, networks, and subnetworks, along with default values for certain TCP parameters to be used on connections with the specified hosts. The table can be displayed with the ndd command as follows:

example# ndd /dev/tcp tcp_host_param Hash HSP Address Subnet Mask Send Receive TStamp 027 fc31eea4 129.154.000.000 255.255.255.000 0000008192 0000008192 0 131 fc308244 129.154.152.000 000.000.000.000 0000032000 0000032000 0 133 fc30bd64 129.154.152.006 000.000.000.000 0000128000 0000128000 1

Each element in the table specifies either a host, a network (with optional subnet mask), or a subnet, along with the default send buffer space and receive buffer space, and a flag indicating whether timestamps are to be used.

The default values specified in the table are used for both active and passive connections (that is, both connect() and listen()). The most applicable match found is used; first the full host address, then the subnet, and finally the network. For subnet recognition to work properly, there must be an entry for that subnet's network which specifies the subnet mask.

The example table above specifies that:

• Connections with host 129.154.152.6 uses send and receive buffer sizes of 128000 bytes, and will use timestamps.

• Connections with other hosts on the 129.154.152 subnet uses send and receive buffer sizes of 32000 bytes.

• Connections with other hosts on the 129.154 network uses send and receive buffer sizes of 8192 bytes.

Elements are added to or removed from the table with ndd as follows:

ndd -set /dev/tcp tcp_host_param '<command>'

<ipaddr>	[ mask <ipmask>] [ sendspace <integer> ]
				[ recvspace <integer> ] [ timestamp { 0 | 1 } ]

or

<ipaddr> delete

For example, the table above was created by:

example# ndd -set /dev/tcp tcp_host_param '129.154.0.0
mask 255.255.255.0 sendspace 8192 recvspace 8192'
            

example# ndd -set /dev/tcp tcp_host_param
'129.154.152.0 sendspace 32000 recvspace 32000'
           

example# ndd -set /dev/tcp tcp_host_param
'129.154.152.6 sendspace 128000 recvspace 128000 
timestamp 1'
 

It could be removed by:

example# ndd -set /dev/tcp tcp_host_param '129.154.152.6 delete'
	 

example# ndd -set /dev/tcp tcp_host_param '129.154.152.0 delete'


example# ndd -set /dev/tcp tcp_host_param '129.154.0.0	 delete'

Networks and subnets are specified by leaving the host bits zero. The same syntax used to add entries can also be used to modify existing entries.

The send and receive space values from the tcp_host_param table will only be used if they are larger than the values set by the user (or obtained from tcp_xmit_hiwat and tcp_recv_hiwat). This is so that the user can specify larger values for improved throughput and not have them erroneously reduced.

If timestamp value in the tcp_host_param table is 1, the timestamp option will be sent to the selected host or hosts when a connection is initiated. However, if the value is 0, the timestamp option may still be sent, depending on the settings of the tcp_tstamp_always and tcp_tstamp_if_wscale options.

Chapter 2 TCP/IP Protocol Suite

This chapter introduces the Solaris implementation of the TCP/IP network protocol suite. The information is particularly geared to network administrators who are unfamiliar with the TCP/IP. (For an introduction to basic network concepts, see Chapter 1, Overview of Network Administration.) If you are an experienced TCP/IP network administrator, consider moving on to chapters covering the tasks you want to perform.

• "Protocol Layers and the OSI Model"

• "TCP/IP Protocol Architecture Model"

• "Standard TCP/IP Services"

• "Data Encapsulation and the TCP/IP Protocol Stack"

Introducing the Internet Protocol Suite

This section presents an in-depth introduction to the protocols that compose TCP/IP. Although the information is conceptual, you should learn the names of the protocols and what each does. This is important because TCP/IP books explain tasks with the assumption that you understand the concepts introduced here.

TCP/IP is the commonly used nickname for the set of network protocols composing the Internet Protocol suite. Many texts use the term "Internet" to describe both the protocol suite and the global wide-area network. In this book, the "TCP/IP" refers specifically to the Internet protocol suite; "Internet" refers to the wide-area network and the bodies that govern it.

To interconnect your TCP/IP network with other networks, you must obtain a unique IP network number. At the time of this writing, IP network numbers are assigned by an organization known as the InterNIC.

If hosts on your network are going to participate in the Internet Domain Name system (DNS), you must obtain and register a unique domain name. The InterNIC also handles the registration of domain names under certain top-level domains such as .com (commercial), .edu (education), and .gov (government). Chapter 3, Planning Your Network, contains more information about the InterNIC. (For more information on DNS, refer to Solaris Naming Administration Guide.)

Protocol Layers and the OSI Model

Most network protocol suites are structured as a series of layers, sometimes referred to collectively as a protocol stack. Each layer is designed for a specific purpose and exists on both the sending and receiving hosts. Each is designed so that a specific layer on one machine sends or receives exactly the same object sent or received by its peer process on another machine. These activities take place independently from what is going on in layers above or below the layer under consideration. In other words, each layer on a host acts independently of other layers on the same machine, and in concert with the same layer on other hosts.

OSI Reference Model

Most network protocol suites are viewed as structured in layers. This is a result of the Open Systems Interconnect (OSI) Reference Model designed by the International Standards Organization (ISO). The OSI model describes network activities as having a structure of seven layers, each of which has one or more protocols associated with it. The layers represent data transfer operations common to all types of data transfers among cooperating networks.

The protocol layers of the OSI Reference Model are traditionally listed from the top (layer 7) to the bottom (layer 1) up, as shown in Table 2-1.

The operations defined by the OSI model are conceptual and not unique to any particular network protocol suite. For example, the OSI network protocol suite implements all seven layers of the OSI Reference Model. TCP/IP uses some of OSI model layers and combines others. Other network protocols, such as SNA, add an eighth layer.

TCP/IP Protocol Architecture Model

The OSI model describes an idealized network communications protocol family. TCP/IP does not correspond to this model directly, as it either combines several OSI layers into a single layer, or does not use certain layers at all. Table 2-2 shows the layers of the Solaris implementation of TCP/IP, listed from topmost layer (application) to lowest (physical network).

The table shows the TCP/IP protocol layers, their OSI Model equivalents, and examples of the protocols available at each level of the TCP/IP protocol stack. Each host involved in a communication transaction runs its own implementation of the protocol stack.

Physical Network Layer

The physical network layer specifies the characteristics of the hardware to be used for the network. For example, it specifies the physical characteristics of the communications media. The physical layer of TCP/IP describes hardware standards such as IEEE 802.3, the specification for Ethernet network media, and RS-232, the specification for standard pin connectors.

Data-Link Layer

The data-link layer identifies the network protocol type of the packet, in this case TCP/IP. It also provides error control and "framing." Examples of data-link layer protocols are Ethernet IEEE 802.2 framing and Point-to-Point Protocol (PPP) framing.

Internet Layer

This layer, also known as the network layer, accepts and delivers packets for the network. It includes the powerful Internet protocol (IP), the ARP protocol, and the ICMP protocol.

IP Protocol

The IP protocol and its associated routing protocols are possibly the most significant of the entire TCP/IP suite. IP is responsible for:

• IP addressing - The IP addressing conventions are part of the IP protocol. (Chapter 3, Planning Your Network, describes IP addressing in complete detail.)

• Host-to-host communications - IP determines the path a packet must take, based on the receiving host's IP address.

• Packet formatting - IP assembles packets into units known as IP datagrams. Datagrams are fully described in "Internet Layer".

• Fragmentation - If a packet is too large for transmission over the network media, IP on the sending host breaks the packet into smaller fragments. IP on the receiving host then reconstructs the fragments into the original packet.

ARP Protocol

The Address Resolution Protocol (ARP) conceptually exists between the data link and Internet layers. ARP assists IP in directing datagrams to the appropriate receiving host by mapping Ethernet addresses (48 bits long) to known IP addresses (32 bits long).

ICMP Protocol

Internet Control Message Protocol (ICMP) is the protocol responsible for detecting network error conditions and reporting on them. ICMP reports on:

• Dropped packets (when packets are arriving too fast to be processed)

• Connectivity failure (when a destination host can't be reached)

• Redirection (which tells a sending host to use another router)

Chapter 6, Troubleshooting TCP/IP, contains more information on the operating system commands that use ICMP for error detection.

Transport Layer

The TCP/IP transport layer protocols ensure that packets arrive in sequence and without error, by swapping acknowledgments of data reception, and retransmitting lost packets. This type of communication is known as "end-to-end." Transport layer protocols at this level are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

TCP Protocol

TCP enables applications to communicate with each other as though connected by a physical circuit. TCP sends data in a form that appears to be transmitted in a character-by-character fashion, rather than as discreet packets. This transmission consists of a starting point, which opens the connection, the entire transmission in byte order, and an ending point, which closes the connection.

TCP attaches a header onto the transmitted data. This header contains a large number of parameters that help processes on the sending machine connect to peer processes on the receiving machine.

TCP confirms that a packet has reached its destination by establishing an end-to-end connection between sending and receiving hosts. TCP is therefore considered a "reliable, connection-oriented" protocol.

UDP Protocol

UDP, the other transport layer protocol, provides datagram delivery service. It does not provide any means of verifying that connection was ever achieved between receiving and sending hosts. Because UDP eliminates the processes of establishing and verifying connections, applications that send small amounts of data use it rather than TCP.

Application Layer

The application layer defines standard Internet services and network applications that anyone can use. These services work with the transport layer to send and receive data. There are many applications layer protocols, some of which you probably already use. Some of the protocols include:

• Standard TCP/IP services such as the ftp, tftp, and telnet commands

• UNIX "r" commands, such as rlogin and rsh

• Name services, such as NIS+ and Domain Name System (DNS)

• File services, such as NFS

• Simple Network Management Protocol (SNMP), which enables network management

• RIP and RDISC routing protocols

Standard TCP/IP Services

• FTP and Anonymous FTP - The File Transfer Protocol (FTP) transfers files to and from a remote network. The protocol includes the ftp command (local machine) and the in.ftpd daemon (remote machine). FTP enables a user to specify the name of the remote host and file transfer command options on the local host's command line. The in.ftpd daemon on the remote host then handles the requests from the local host. Unlike rcp, ftp works even when the remote computer does not run a UNIX-based operating system. A user must log in to the remote computer to make an ftp connection unless it has been set up to allow anonymous FTP.

  You can now obtain a wealth of materials from anonymous FTP servers connected to the Internet. These servers are set up by universities and other institutions to make certain software, research papers, and other information available to the public domain. When you log in to this type of server, you use the login name anonymous, hence the term "anonymous FTP servers."

  Using anonymous FTP and setting up anonymous FTP servers is outside the scope of this manual. However, many trade books, such as The Whole Internet User's Guide & Catalog, discuss anonymous FTP in detail. Instructions for using FTP to reach standard machines are in System Administration Guide. The ftp(1) man page describes all ftp command options, including those invoked through the command interpreter. The ftpd(1M) man page describes the services provided by the daemon in.ftpd.

• Telnet - The Telnet protocol enables terminals and terminal-oriented processes to communicate on a network running TCP/IP. It is implemented as the program telnet (on local machines) and the daemon in.telnet (on remote machines). Telnet provides a user interface through which two hosts can communicate on a character-by-character or line-by-line basis. The application includes a set of commands that are fully documented in the telnet(1) man page.

• TFTP - The trivial file transfer protocol (tftp) provides functions similar to ftp, but it does not establish ftp's interactive connection. As a result, users cannot list the contents of a directory or change directories. This means that a user must know the full name of the file to be copied. The tftp(1) man page describes the tftp command set.

UNIX "r" Commands

The UNIX "r" commands enable users to issue commands on their local machines that are actually carried out on the remote host that they specify. These commands include

• rcp

• rlogin

• rsh

Instructions for using these commands are in Solaris Advanced User's Guide and in rcp(1), rlogin(1), and rsh(1) man pages.

Name Services

Two name services are available from the Solaris implementation of TCP/IP: NIS+ and DNS.

• NIS+ - NIS+ provides centralized control over network administration services, such as mapping host names to IP and Ethernet addresses, verifying passwords, and so on. See Solaris Naming Administration Guide for complete details.

• Domain Name System - The Domain Name System (DNS) provides host names to the IP address service. It also serves as a database for mail administration. For a complete description of this service, see Solaris Naming Administration Guide. See also the in.named(1M) man page.

File Services

The NFS application layer protocol provides file services for the Solaris operating system. You can find complete information about the NFS service in NFS Administration Guide.

Network Administration

The Simple Network Management Protocol (SNMP) enables you to view the layout of your network, view status of key machines, and obtain complex network statistics from graphical user interface based software. Many companies offer network management packages that implement SNMP; SunNet Manager^TM software is an example.

Routing Protocols

The Routing Information Protocol (RIP) and the Router Discovery Protocol (RDISC) are two routing protocols for TCP/IP networks. They are described in Chapter 5, Configuring Routers.

How the TCP/IP Protocols Handle Data Communications

When a user issues a command that uses a TCP/IP application layer protocol, a chain of events is set in motion. The user's command or message passes through the TCP/IP protocol stack on the local machine, and then across the network media to the protocols on the recipient. The protocols at each layer on the sending host add information to the original data.

As the user's command makes its way through the protocol stack, protocols on each layer of the sending host also interact with their peers on the receiving host. Figure 2-1 shows this interaction.

Figure 2-1 How a Packet Travels Through the TCP/IP Stack

Data Encapsulation and the TCP/IP Protocol Stack

The packet is the basic unit of information transferred across a network, consisting, at a minimum, of a header with the sending and receiving hosts' addresses, and a body with the data to be transferred. As the packet travels through the TCP/IP protocol stack, the protocols at each layer either add or remove fields from the basic header. When a protocol on the sending host adds data to the packet header, the process is called data encapsulation. Moreover, each layer has a different term for the altered packet, as shown in Figure 2-1.

This section summarizes the life cycle of a packet from the time the user issues a command or sends a message to the time it is received by the appropriate application on the receiving host.

Application Layer--User Initiates Communication

The packet's history begins when a user on one host sends a message or issues a command that must access a remote host. The application protocol associated with the command or message formats the packet so that it can be handled by the appropriate transport layer protocol, TCP or UDP.

Suppose the user issues an rlogin command to log in to the remote host, as shown in Figure 2-1. The rlogin command uses the TCP transport layer protocol. TCP expects to receive data in the form of a stream of bytes containing the information in the command. Therefore, rlogin sends this data as a TCP stream.

Not all application layer protocols use TCP, however. Suppose a user wants to mount a file system on a remote host, thus initiating the NIS+ application layer protocol. NIS+ uses the UDP transport layer protocol. Therefore, the packet containing the command must be formatted in a manner that UDP expects. This type of packet is referred to as a message.

Transport Layer--Data Encapsulation Begins

When the data arrives at the transport layer, the protocols at the layer start the process of data encapsulation. The end result depends on whether TCP or UDP has handled the information.

TCP Segmentation

TCP is often called a "connection-oriented" protocol because it ensures the successful delivery of data to the receiving host. Figure 2-1 shows how the TCP protocol receives the stream from the rlogin command. TCP divides the data received from the application layer into segments and attaches a header to each segment.

Segment headers contain sender and recipient ports, segment ordering information, and a data field known as a checksum. The TCP protocols on both hosts use the checksum data to determine whether data has transferred without error.

Establishing a TCP Connection

In addition, TCP uses segments to determine whether the receiving host is ready to receive the data. When the sending TCP wants to establish connections, it sends a segment called a SYN to the peer TCP protocol running on the receiving host. The receiving TCP returns a segment called an ACK to acknowledge the successful receipt of the segment. The sending TCP sends another ACK segment, then proceeds to send the data. This exchange of control information is referred to as a three-way handshake.

UDP Packets

UDP is a "connectionless" protocol. Unlike TCP, it does not check to make sure that data arrived at the receiving host. Instead, UDP takes the message received from the application layer and formats it into UDP packets. UDP attaches a header to each packet, which contains the sending and receiving host ports, a field with the length of the packet, and a checksum.

The sending UDP process attempts to send the packet to its peer UDP process on the receiving host. The application layer determines whether the receiving UDP process acknowledges that the packet was received. UDP requires no notification of receipt. UDP does not use the three-way handshake.

Internet Layer

As shown in Figure 2-1, both TCP and UDP pass their segments and packets down to the Internet layer, where they are handled by the IP protocol. IP prepares them for delivery by formatting them into units called IP datagrams. IP then determines the IP addresses for the datagrams, so they can be delivered effectively to the receiving host.

IP Datagrams

IP attaches an IP header to the segment or packet's header in addition to the information added by TCP or UDP. Information in the IP header includes the IP addresses of the sending and receiving hosts, datagram length, and datagram sequence order. This information is provided in case the datagram exceeds the allowable byte size for network packets and must be fragmented.

Data-Link Layer--Framing Takes Place

Data-link layer protocols such as PPP format the IP datagram into a frame. They attach a third header and a footer to "frame" the datagram. The frame header includes a cyclical redundancy check (CRC) field that checks for errors as the frame travels over the network media. Then the data-link layer passes the frame to the physical layer.

Physical Network Layer--Preparing the Frame for Transmission

The physical network layer on the sending host receives the frames and converts the IP addresses into the hardware addresses appropriate to the network media. The physical network layer then sends the frame out over the network media.

How the Receiving Host Handles the Packet

When the packet arrives on the receiving host, it travels through the TCP/IP protocol stack in the reverse order from that which it took on the sender. Figure 2-1 illustrates this path. Moreover, each protocol on the receiving host strips off header information attached to the packet by its peer on the sending host. Here is what happens.

1. Physical Network Layer receives the packet in its frame form. It computes the CRC of the packet, then sends the frame to the data link layer.

2. Data-Link Layer verifies that the CRC for the frame is correct and strips off the frame header and CRC. Finally, the data link protocol sends the frame to the Internet layer.

3. Internet Layer reads information in the header to identify the transmission and determine if it is a fragment. If the transmission was fragmented, IP reassembles the fragments into the original datagram. It then strips off the IP header and passes the datagram on to transport layer protocols.

4. Transport Layer (TCP and UDP) reads the header to determine which application layer protocol must receive the data. Then TCP or UDP strips off its related header and sends the message or stream up to the receiving application.

5. Application Layer receives the message and performs the operation requested by the sending host.

Finding Out More About TCP/IP and the Internet

A great deal of information about TCP/IP and the Internet has been published. If you require specific information that is not covered in this text, you probably can find what you need in the sources cited below.

Computer Trade Books

Many books about TCP/IP and the Internet are available from your local library or computer bookstore. Three highly recommended books are

• Craig Hunt. TCP/IP Network Administration - This book contains some theory and much practical information for managing a heterogeneous TCP/IP network.

• W. Richard Stevens. TCP/IP Illustrated, Volume I - This book is an in-depth explanation of the TCP/IP protocols. It is ideal for network administrators requiring a technical background in TCP/IP and for network programmers.

• Ed Krol. The Whole Internet User's Guide & Catalog - This book is ideal for anyone interested in using the many tools available for retrieving information over the Internet.

RFCs and FYIs

Since 1969, developers working on the Internet protocol suite have described their protocols and related subjects in documents known as Requests for Comments (RFCs). Many RFCs are specifications for particular TCP/IP protocols and describe standards with which software implementing the protocols must comply. Other RFCs discuss the Internet, its topology, and its governing bodies. Still other RFCs explain how to manage TCP/IP applications, such as DNS.

All RFCs must be approved by the Internet Architecture Board (IAB) before they are placed in the public domain. Typically, the information in RFCs is geared to developers and other highly technical readers, though this isn`t always the case.

In recent years, For Your Information (FYI) documents have appeared as a subset of the RFCs. The FYIs contain information that does not deal with Internet standards; rather, they contain Internet information of a more general nature. For example, FYI documents include a bibliography listing introductory TCP/IP books and papers, an exhaustive compendium of Internet-related software tools, and a glossary of Internet and general networking terms.

You'll find references to relevant RFCs throughout this guide and other books in the Solaris 2.6 System Administrator set.

How to Obtain RFCs

The InterNIC Directory and Database Service maintains the repository of RFCs. If you have a connection to the Internet, you can retrieve online RFCs as follows:

• Through ftp, by sending your requests to the InterNIC directory and database server ds.internic.net. Your request should have the format:

  rfc/rfc.rfcnum.txt or rfc/rfc.rfcnum.ps

  where rfcnum represents the number of the RFC you want. For example, if you wanted to retrieve RFC 1540 in PostScript\256 format, you would request rfc/rfc.1540.ps.

• Through electronic mail, by emailing mailserv@ds.internic.net. This is an automatic server that expects the body of your request message to have the format:

  document-by-name rfcrfcnum or document-by-name rfcrfcnum.ps

• Through a World Wide Web browser, by specifying the URL http://ds.internic.net/ds/dspg1intdoc.html. The home page is http://ds.internic.net

If you need an online index of RFCs, send electronic mail to ds.internic.net with a message containing the request document-by-name rfc-index.

The InterNIC information above is current as of this writing. However, the Internet is expanding at a fast pace, and the addresses listed might no longer be current when you read this manual.

Chapter 3 Planning Your Network

This chapter describes the issues you must resolve in order to create your network in an organized, cost-effective manner. After you have resolved these issues, you can devise a plan for your network to follow as you set it up and administer it in the future.

• "Designing the Network"

• "Designing Your IP Addressing Scheme"

• "Registering Your Network"

• "Naming Entities on Your Network"

• "Adding Routers"

• "Network Topology"

If you are unfamiliar with TCP/IP fundamentals, refer to Chapter 2, TCP/IP Protocol Suite.

Designing the Network

The first phase in the life of a network--designing the network--involves making decisions about the type of network that best suits the needs of your organization. Some of the planning decisions you make will involve network hardware; for example:

• Number of host machines your network can support

• Type of network media to use: Ethernet, token ring, FDDI, and so on

• Network topology; that is, the physical layout and connections of the network hardware

• Types of hosts the network will support: standalone, diskless, and dataless

Based on these factors, you can determine the size of your local-area network.

Planning the network hardware is outside the scope of this manual. Refer to the manuals that came with your hardware for assistance.

Factors Involved in Network Planning

After you have completed your hardware plan, you are ready to begin network planning, from the software perspective.

As part of the planning process you must:

1. Obtain a network number and, if applicable, register your network domain with the InterNIC.

2. Devise an IP addressing scheme for your hosts, after you receive your IP network number.

3. Create a list containing the IP addresses and host names of all machines that make up your network, which you can use as you build network databases.

4. Determine which name service to use on your network: NIS, NIS+, DNS, or the network databases in the local /etc directory.

5. Establish administrative subdivisions, if appropriate for your network.

6. Determine if your network is large enough to require routers, and, if appropriate, create a network topology that supports them.

7. Set up subnets, if appropriate for your network.

The remainder of Chapter 3, Planning Your Network, explains how to plan your network with these factors in mind.

Setting Up an IP Addressing Scheme

The number of machines you expect to support will affect several decisions you will need to make at this stage of setting up a network for your site. Your organization may require a small network of several dozen standalone machines located on one floor of a single building. Alternatively, you may need to set up a network with more than 1000 hosts in several buildings. This arrangement may require you to further divide your network into subdivisions called subnets. The size of your prospective network will affect the

• Network class you apply for

• Network number you receive

• IP addressing scheme you use for your network

Obtaining a network number and then establishing an IP addressing scheme is one of the most important tasks of the planning phase of network administration.

Parts of the IP Address

Each network running TCP/IP must have a unique network number, and every machine on it must have a unique IP address. It is important to understand how IP addresses are constructed before you register your network and obtain its network number.

The IP address is a 32-bit number that uniquely identifies a network interface on a machine. An IP address is typically written in decimal digits, formatted as four 8-bit fields separated by periods. Each 8-bit field represents a byte of the IP address. This form of representing the bytes of an IP address is often referred to as the dotted-decimal format.

The bytes of the IP address are further classified into two parts: the network part and the host part. Figure 3-1 shows the component parts of a typical IP address, 129.144.50.56.

Figure 3-1 Parts of an IP Address

Network Part

This part specifies the unique number assigned to your network. It also identifies the class of network assigned. In Figure 3-1, the network part takes up two bytes of the IP address.

Host Part

This is the part of the IP address that you assign to each host. It uniquely identifies this machine on your network. Note that for each host on your network, the network part of the address will be the same, but the host part must be different.

Subnet Number (Optional)

Local networks with large numbers of hosts are sometimes divided into subnets. If you choose to divide your network into subnets, you need to assign a subnet number for the subnet. You can maximize the efficiency of the IP address space by using some of the bits from the host number part of the IP address as a network identifier. When used as a network identifier, the specified part of the address becomes the subnet number. You create a subnet number by using a netmask, which is a bit mask that selects the network and subnet parts of an IP address. (Refer to "Creating the Network Mask" for full details.)

Network Classes

The first step in planning for IP addressing on your network is to determine which network class is appropriate for your network. After you have done this, you can take the crucial second step: obtain the network number from the InterNIC addressing authority.

Currently there are three classes of TCP/IP networks. Each class uses the 32-bit IP address space differently, providing more or fewer bits for the network part of the address. These classes are class A, class B, and class C.

Class A Network Numbers

A class A network number uses the first eight bits of the IP address as its "network part." The remaining 24 bits comprise the host part of the IP address, as illustrated in Figure 3-2 below.

Figure 3-2 Byte Assignment in a Class A Address

The values assigned to the first byte of class A network numbers fall within the range 0-127. Consider the IP address 75.4.10.4. The value 75 in the first byte indicates that the host is on a class A network. The remaining bytes, 4.10.4, establish the host address. The InterNIC assigns only the first byte of a class A number. Use of the remaining three bytes is left to the discretion of the owner of the network number. Only 127 class A networks can exist. Each one of these numbers can accommodate up to 16,777,214 hosts.

Class B Network Numbers

A class B network number uses 16 bits for the network number and 16 bits for host numbers. The first byte of a class B network number is in the range 128-191. In the number 129.144.50.56, the first two bytes, 129.144, are assigned by the InterNIC, and comprise the network address. The last two bytes, 50.56, make up the host address, and are assigned at the discretion of the owner of the network number. Figure 3-3 graphically illustrates a class B address.

Figure 3-3 Byte Assignment in a Class B Address

Class B is typically assigned to organizations with many hosts on their networks.

Class C Network Numbers

Class C network numbers use 24 bits for the network number and 8 bits for host numbers. Class C network numbers are appropriate for networks with few hosts--the maximum being 254. A class C network number occupies the first three bytes of an IP address. Only the fourth byte is assigned at the discretion of the network owners. Figure 3-4 graphically represents the bytes in a class C address.

Figure 3-4 Byte Assignment in a Class C Address

The first byte of a class C network number covers the range 192-223. The second and third each cover the range 1- 255. A typical class C address might be 192.5.2.5. The first three bytes, 192.5.2, form the network number. The final byte in this example, 5, is the host number.

Administering Network Numbers

If your organization has been assigned more than one network number, or uses subnets, appoint a centralized authority within your organization to assign network numbers. That authority should maintain control of a pool of assigned network numbers, assigning network, subnet, and host numbers as required. To prevent problems, make sure that duplicate or random network numbers do not exist in your organization.

Designing Your IP Addressing Scheme

After you have received your network number, you can then plan how you will assign the host parts of the IP address.

Table 3-1 shows the division of the IP address space into network and host address spaces. For each class, "range" specifies the range of decimal values for the first byte of the network number. "Network address" indicates the number of bytes of the IP address that are dedicated to the network part of the address, with each byte represented by xxx. "Host address" indicates the number of bytes dedicated to the host part of the address. For example, in a class A network address, the first byte is dedicated to the network, and the last three are dedicated to the host. The opposite is true for a class C network.

The numbers in the first byte of the IP address define whether the network is class A, B, or C and are always assigned by the InterNIC. The remaining three bytes have a range from 0-255. The numbers 0 and 255 are reserved; you can assign the numbers 1-254 to each byte depending on the network number assigned to you.

Table 3-2 shows which bytes of the IP address are assigned to you and the range of numbers within each byte that are available for you to assign to your hosts.

How IP Addresses Apply to Network Interfaces

In order to connect to the network, a computer must have at least one network interface, as explained in "Network Interfaces". Each network interface must have its own unique IP address. The IP address that you give to a host is assigned to its network interface, sometimes referred to as the primary network interface. If you add a second network interface to a machine, it must have its own unique IP number. Adding a second network interface changes the function of a machine from a host to a router, as explained in Chapter 5, Configuring Routers. If you add a second network interface to a host and disable routing, the host is then considered a multihomed host.

Each network interface has a device name, device driver, and associated device file in the /devices directory. The network interface might have a device name such as le0 or smc0, device names for two commonly used Ethernet interfaces.

This book assumes that your machines have Ethernet network interfaces. If you plan to use different network media, refer to the manuals that came with the network interface for configuration information.

Naming Entities on Your Network

After you have received your assigned network number and given IP addresses to your hosts, the next task is to assign names to the hosts and determine how you will handle name services on your network. You will use these names when you initially set up your network and, later, for expanding your network through routers or PPP.

The TCP/IP protocols locate a machine on a network by using its IP address. However, humans find it much easier to identify a machine if it has an understandable name. Therefore, the TCP/IP protocols (and the Solaris operating system) require both the IP address and the host name to uniquely identify a machine.

From a TCP/IP perspective, a network is a set of named entities. A host is an entity with a name. A router is an entity with a name. The network is an entity with a name. A group or department in which the network is installed can also be given a name, as can a division, a region, or a company. In theory, there is virtually no limit to the hierarchy of names that can be used to identify a network and its machines. The term for these named entities is domain.

Administering Host Names

Many sites let users pick host names for their machines. Servers also require at least one host name, which is associated with the IP address of its primary network interface.

As network administrator, you must ensure that each host name in your domain is unique. In other words, no two machines on your network could both have the name "fred," although the machine "fred" might have multiple IP addresses.

When planning your network, make a list of IP addresses and their associated host names for easy access during the setup process. The list can help you verify that all host names are unique.

Selecting a Name Service

The Solaris operating system gives you the option of using four types of name services: local files, NIS, NIS+, and DNS. Name services maintain critical information about the machines on a network, such as the host names, IP addresses, Ethernet addresses, and the like.

Network Databases

When you install the operating system, you supply the host name and IP address of your server, clients, or standalone machine as part of the procedure. The Solaris installation program enters this information into a network database called the hosts database. The hosts database is one of a set of network databases that contain information necessary for TCP/IP operation on your network. These databases are read by the name service you select for your network.

Setting up the network databases is a critical part of network configuration. Therefore, you need to decide which name service to use as part of the network planning process. Moreover, the decision to use name services also affects whether or not you organize your network into an administrative domain. Chapter 4, Configuring TCP/IP on the Network, has detailed information on the set of network databases.

Using NIS, NIS+, or DNS for Name Service

The NIS, NIS+, or DNS name services maintain network databases on several servers on the network. Solaris Naming Setup and Configuration Guide fully describes these name services and explains how to set them up. It also explains the "namespace" and "administrative domain" concepts in complete detail. If you are changing name services from NIS to NIS+, refer to NIS+ Transition Guide. You should refer to these manuals to help you decide whether to use these name services on your network.

Using Local Files for Name Service

If you do not implement NIS, NIS+, or DNS, the network will use local files to provide name service. The term "local files" refers to the series of files in the /etc directory that the network databases use. The procedures in this book assume you are using local files for your name service, unless otherwise indicated.

If you decide to use local files as the name service for your network, you can set up another name service at a later date.

Domain Names

Many networks organize their hosts and routers into a hierarchy of administrative domains. If you are going to use NIS, NIS+, or the DNS name services, you must select a domain name for your organization that is unique worldwide. To ensure that your domain name is unique, you should register it with the InterNIC. This is especially important if you plan to use DNS.

The domain name structure is hierarchical. A new domain typically is located below an existing, related domain. For example, the domain name for a subsidiary company could be located below the domain of the parent company. If it has no other relationship, an organization can place its domain name directly under one of the existing top-level domains.

Examples of top-level domains include:

• .com - Commercial companies (international in scope)

• .edu - Educational institutions (international in scope)

• .gov - U.S. government agencies

• .fr - France

The name that identifies your organization is one that you select, with the provision that it is unique.

Administrative Subdivisions

The question of administrative subdivisions deals with matters of size and control. The more hosts and servers you have in a network, the more complex your management task. You may wish to handle such situations by setting up additional administrative divisions in the form of more additional networks of a particular class or by dividing existing networks into subnets. The decision as to whether to set up administrative subdivisions for your network hinges on the following factors:

• How large is the network?

  A single network of several hundred hosts, all in the same physical location and requiring the same administrative services, can be handled by a single administrative division. On the other hand, a network of fewer machines, divided into a number of subnets and physically scattered over an extensive geographic area, would be likely to benefit from the establishment of several administrative subdivisions.

• Do users on the network have similar needs?

  For example, you may have a network that is confined to a single building and supports a relatively small number of machines. These machines are divided among a number of subnetworks, each supporting groups of users with different needs. Such a case could call for an administrative subdivision for each subnet.

  Solaris Naming Administration Guide discusses administrative subdivisions in detail.

Registering Your Network

Before you assign IP addresses to the machines on your Solaris network, you must obtain a network number from the InterNIC. Moreover, if you plan to use administrative domains, you should register them with the InterNIC.

InterNIC and InterNIC Registration Services

The InterNIC was created in 1993 to act as a central body where users of the Internet could go for information, such as

• What the Internet's policies are

• How to access the Internet, including training services

• What resources are available to Internet users, such as anonymous FTP servers, Usenet user groups, and so on.

The InterNIC also includes the InterNIC Registration Services, the organization with which you register your TCP/IP network. The InterNIC Registration Services provide templates for obtaining a network number and for registering your domain. Two points to remember about registration are:

• The InterNIC assigns network numbers.

Do not arbitrarily assign network numbers to your network, even if you do not plan to attach it to other existing TCP/IP networks.

Subnet numbers are not assigned by the InterNIC. Rather, they are composed partly of the assigned network number and numbers that you define, as explained in "What is Subnetting".

• You--not InterNIC--determine the domain name for your network and then register it with the InterNIC.

How to Contact the InterNIC

You can reach the InterNIC Registration Services by:

• Mail

  Write to:

  Network Solutions 
  Attn: InterNIC Registration Services
  505 Huntmar Park Drive 
  Herndon, Virginia 22070

• Telephone

  The phone number is 1-703-742-4777. Phone service is available from 7 a.m. to 7 p.m. Eastern Standard Time.

• Electronic mail

  Send email regarding network registration to: Hostmaster@rs.internic.net

• Anonymous FTP or Telnet inquiries, through the Gopher and WAIS interfaces. Connect to rs.internic.net. (Anonymous FTP and Telnet are outside the scope of this book; however, books on these subjects are available in computer bookstores.)

Adding Routers

Recall that in TCP/IP, two types of entities exist on a network: hosts and routers. All networks must have hosts, while not all networks require routers. Whether you use routers should depend on the physical topology of the network. This section introduces the concepts of network topology and routing, important when you decide to add another network to your existing network environment.

Network Topology

Network topology describes how networks fit together. Routers are the entities that connect networks to each other. From a TCP/IP perspective, a router is any machine that has two or more network interfaces. However, the machine cannot function as a router until properly configured, as described in Chapter 5, Configuring Routers.

Two or more networks can be connected together by routers to form larger internetworks. The routers must be configured to pass packets between two adjacent networks. They also should be able to pass packets to networks that lie beyond the adjacent networks.

Figure 3-5 shows the basic parts of a network topology. The first illustration shows a simple configuration of two networks connected by a single router. The second shows a configuration of three networks, interconnected by two routers. In the first case, network 1 and network 2 are joined into a larger internetwork by router R. In the second case, router R1 connects networks 1 and 2, and router R2 connects networks 2 and 3, thus forming a network made up of networks 1, 2, and 3.

Figure 3-5 Basic Network Topology

Routers join networks into internetworks and route packets between them based on the addresses of the destination network. As internetworks grow more complex, each router must make more and more decisions regarding where packets are to be sent.

A step up in complexity is the case shown in Figure 3-6. Networks 1 and 3 are directly connected by a router R3. The reason for such redundancy is reliability. If network 2 goes down, router R3 still provides a route between networks 1 and 3. Any number of networks can be interconnected and communicate as long as they all adhere to the same network protocols.

Figure 3-6 Providing an Additional Path Between Networks

How Routers Transfer Packets

Routing decisions on a network are based on the network portion of the IP address of the recipient that is contained in the packet header. If this address includes the network number of the local network, the packet goes directly to the host with that IP address. If the network number is not the local network, the packet goes to the router on the local network.

Routers maintain routing information in routing tables. These tables contain the IP address of the hosts and routers on the networks to which the router is connected. The tables also contain pointers to these networks. When a router gets a packet, it consults its routing table to see if it lists the destination address in the header. If the table does not contain the destination address, the router forwards the packet to another router listed in its routing table. Refer to Chapter 5, Configuring Routers, for detailed information on routers.

Figure 3-7 shows a network topology with three networks connected by two routers.

Figure 3-7 Three Interconnected Networks

Router R1 connects networks 192.9.200 and 192.9.201. Router R2 connects networks 192.9.201 and 192.9.202. If host A on network 192.9.200 sends a message to host B on network 192.9.202, this is what happens.

1. Host A sends a packet out over network 192.9.200. The packet header contains the IP address of the recipient host B, 192.9.202.10.

2. None of the machines on network 192.9.200 has the IP address 192.9.202.10. Therefore, router R1 accepts the packet.

3. Router R1 examines its routing tables. No machine on network 192.9.201 has the address 192.9.202.10. However, the routing tables do list router R2.

4. R1 then selects R2 as the "next hop" router and sends the packet to R2.

5. Because R2 connects network 192.9.201 to 192.9.202, it has routing information for host B. Router R2 then forwards the packet to network 192.9.202, where it is accepted by host B.

Chapter 4 Configuring TCP/IP on the Network

The second phase of network administration involves setting up the network. This consists of assembling the hardware which makes up the physical part of the network, and configuring TCP/IP. This chapter explains how to configure TCP/IP, including:

• Determining the host configuration mode for each machine on your network

• Setting up the subnet mask for your network (optional)

• Configuring TCP/IP on the machines that run in local files mode

• Configuring a network configuration server

• Configuring TCP/IP on machines that run in network client mode

• Editing the network databases, based on the name service you have selected for your network

• Configuring the name service switch file

• "Before You Configure TCP/IP"

• "Determining Host Configuration Modes"

• "TCP/IP Configuration Files"

• "hosts Database"

• "Creating the Network Mask"

• "How Name Services Affect Network Databases"

• "nsswitch.conf File -- Specifying Which Name Service to Use"

• "Network Configuration Procedures"

• "Configuring Standard TCP/IP Services"

Before You Configure TCP/IP

Before configuring the TCP/IP software, you should have:

1. Designed the network topology, if you are the network designer. (See "Network Topology" for details.)

2. Obtained a network number from your Internet addressing authority. (See "Network Classes".)

3. Assembled the network hardware according to the topology designed and assured that the hardware is functioning. (See the hardware manuals and "Network Topology".)

4. Run any configuration software required by network interfaces and routers, if applicable. (See Chapter 3, Planning Your Network, and Chapter 5, Configuring Routers, for information on routers. If you have purchased network interfaces for your machines, refer to the manuals that came with them for software configuration requirements.)

5. Planned the IP addressing scheme for the network, including subnet addressing, if applicable. (See "Designing Your IP Addressing Scheme".)

6. Assigned IP numbers and host names to all machines involved in the network. (See "Designing Your IP Addressing Scheme".)

7. Determined which name service your network uses: NIS, NIS+, DNS, or local files. (See Solaris Naming Administration Guide.)

8. Selected domain names for your network, if applicable. (See Solaris Naming Administration Guide.)

9. Installed the operating system on at least one machine on the prospective network. (See Solaris Advanced Installation Guide.)

Determining Host Configuration Modes

One of your key functions as a network administrator is configuring TCP/IP to run on hosts and routers (if applicable). You can set up these machines to obtain configuration information from two sources: files on the local machine or files located on other machines on the network. Configuration information includes:

• Host name of a machine

• IP address of the machine

• Domain name to which the machine belongs

• Default router

• Netmask in use on the machine's network

A machine that obtains TCP/IP configuration information from local files is said to be operating in local files mode. A machine that obtains TCP/IP configuration information from a remote machine is said to be operating in network client mode.

Machines That Should Run in Local Files Mode

To run in local files mode, a machine must have local copies of the TCP/IP configuration files. These files are described in "TCP/IP Configuration Files". The machine should have its own disk, though this is not strictly necessary.

Most servers should run in local file mode. This requirement includes:

• Network configuration servers

• NFS servers

• Name servers supplying NIS, NIS+, or DNS services

• Mail servers

Additionally, routers should run in local files mode.

Machines that exclusively function as print servers do not need to run in local files mode. Whether individual hosts should run in local files mode depends on the size of your network.

If you are running a very small network, the amount of work involved in maintaining these files on individual hosts is manageable. If your network serves hundreds of hosts, the task becomes difficult, even with the network divided into a number of administrative subdomains. Thus, for large networks, using local files mode is usually less efficient. On the other hand, because routers and servers must be self-sufficient, they should be configured in local files mode.

Network Configuration Servers

Network configuration servers are the machines that supply the TCP/IP configuration information to hosts configured in network client mode. These servers support three booting protocols:

• RARP - Reverse Address Resolution Protocol (RARP) maps known Ethernet addresses (48 bits) to IP addresses (32 bits), the reverse of ARP. When you run RARP on a network configuration server, this enables hosts running in network client mode to obtain their IP addresses and TCP/IP configuration files from the server. The in.rarpd daemon enables RARP services. Refer to the in.rarpd(1M) man page for complete details.

• TFTP - Trivial File Transfer Protocol (TFTP) is an application that transfers files between remote machines. The in.tftpd daemon carries out TFTP services, enabling file transfer between network configuration servers and their network clients.

• bootparams - The bootparams protocol supplies parameters for booting that are required by diskless clients. The rpc.bootparamd daemon carries out these services.

Network configuration servers can also can function as NFS file servers.

If you are going to configure any hosts as network clients, then you must also configure at least one machine on your network as a network configuration server. If your network is subnetted, then you must have at least one network configuration server for each subnet with network clients.

Machines That Are Network Clients

Any host that gets its configuration information from a network configuration server is said to be "operating" in network client mode. Machines configured as network clients do not require local copies of the TCP/IP configuration files.

Network client mode greatly simplifies administration of large networks. It minimizes the number of configuration tasks that must be performed on individual hosts and assures that all machines on the network adhere to the same configuration standards.

You can configure network client mode on all types of computers, from fully standalone systems to diskless and dataless machines. Although it is possible to configure routers and servers in network client mode, local files mode is a better choice for these machines. Routers and servers should be as self-sufficient as possible.

Diskless Booting

Setting up systems for diskless booting is described in the System Administration Guide.

Mixed Configurations

Due to the flexibility of the system, configurations are not limited to either an all-local-hosts mode or an all-network-client mode. The configuration of routers and servers typifies this, in that routers and servers should always be configured in local mode. For hosts, you can use any combination of local and network client mode you want.

Sample Network

Figure 4-1 shows the hosts of a fictional network with the network number 192.9.200. The network includes one network configuration server, the machine sahara. It serves the diskless client ahaggar. Machines tenere and nubian have their own disks and run in local files mode. Machine faiyum also has a disk but operates in network client mode.

Finally, the machine timbuktu is configured as a router. It includes two network interfaces, one named timbuktu on network 192.9.200 and one named timbuktu-201 on network 192.9.201. Both networks are in the organizational domain deserts.worldwide.com. The domain uses local files as its name service.

Most examples in this chapter use the network shown in Figure 4-1 as their basis.

Figure 4-1 Hosts in a Sample Network

TCP/IP Configuration Files

Each machine on the network gets its TCP/IP configuration information from the following TCP/IP configuration files and network databases:

• /etc/hostname.interface file

• /etc/nodename file

• /etc/defaultdomain file

• /etc/defaultrouter file (optional)

• hosts database

• netmasks database (optional)

The Solaris installation program creates these files as part of the installation process. You can also edit the files manually, as explained in this section. The hosts and netmasks databases are two of the network databases read by the name services available on Solaris networks. "Network Databases and nsswitch.conf File" describes the concept of network databases in detail.

/etc/hostname.interface File

This file defines the network interfaces on the local host. At least one /etc/hostname.interface file should exist on the local machine. The Solaris installation program creates this file for you. In the file name, interface is replaced by the device name of the primary network interface.

The file contains only one entry: the host name or IP address associated with the network interface. For example, suppose smc0 is the primary network interface for a machine called ahaggar. Its /etc/hostname.interface file would have the name /etc/hostname.smc0; the file would contain the entry ahaggar.

For Multiple Network Interfaces

If a machine contains more than one network interface, you must create additional /etc/hostname.interface files for the additional network interfaces. You must create these files with a text editor; the Solaris installation program does not create them for you.

For example, consider the machine timbuktu shown in Figure 4-1. It has two network interfaces and functions as a router. The primary network interface le0 is connected to network 192.9.200. Its IP address is 192.9.200.70, and its host name is timbuktu. The Solaris installation program creates the file /etc/hostname.le0 for the primary network interface and enters the host name timbuktu in the file.

The second network interface is le1; it is connected to network 192.9.201. Although this interface is physically installed on machine timbuktu, it must have a separate IP address. Therefore, you have to manually create the /etc/hostname.le1 file for this interface; the entry in the file would be the router`s name, timbuktu-201.

/etc/nodename File

This file should contain one entry: the host name of the local machine. For example, on machine timbuktu, the file /etc/nodename would contain the entry timbuktu.

/etc/defaultdomain File

This file should contain one entry, the fully qualified domain name of the administrative domain to which the local host's network belongs. You can supply this name to the Solaris installation program or edit the file at a later date.

In Figure 4-1, the networks are part of the domain deserts.worldwide, which was classified as a .com domain. Therefore, /etc/defaultdomain should contain the entry deserts.worldwide.com. For more information on network domains, refer to the Solaris Naming Administration Guide.

/etc/defaultrouter File

This file should contain an entry for each router directly connected to the network. The entry should be the name for the network interface that functions as a router between networks.

In Figure 4-1, the network interface le1 connects machine timbuktu with network 192.9.201. This interface has the unique name timbuktu-201. Thus, the machines on network 192.9.200 that are configured in local files mode have the name timbuktu-201 as the entry in /etc/defaultrouter.

hosts Database

The hosts database contains the IP addresses and host names of machines on your network. If you use the NIS, NIS+, or DNS name services, the hosts database is maintained in a database designated for host information. For example, on a network running NIS+, the hosts database is maintained in the host table.

If you use local files for name service, the hosts database is maintained in the /etc/inet/hosts file. This file contains the host names and IP addresses of the primary network interface, other network interfaces attached to the machine, and any other network addresses that the machine must know about.

For compatibility with BSD-based operating systems, the file /etc/hosts is a symbolic link to /etc/inet/hosts.

/etc/inet/hosts File Format

The /etc/inet/hosts file uses this basic syntax: (Refer to the hosts(4) man page for complete syntax information.)

IP-address hostname [nicknames] [#comment]

IP-address contains the IP address for each interface that the local host must know about.

hostname contains the host name assigned to the machine at setup, plus the host names assigned to additional network interfaces that the local host must know about.

[nickname] is an optional field containing a nickname for the host.

[# comment] is an optional field where you can include a comment.

Initial /etc/inet/hosts File

When you run the Solaris installation program on a machine, it sets up the initial /etc/inet/hosts file. This file contains the minimum entries that the local host requires: its loopback address, its IP address, and its host name.

For example, the Solaris installation program might create the following /etc/inet/hosts file for machine ahaggar shown in Figure 4-1:

Example 4-1 /etc/inet/hosts File for Machine ahaggar

127.0.0.1     localhost         loghost    #loopback address
192.9.200.3   ahaggar                      #host name

Loopback Address

In Example 4-1, the IP address 127.0.0.1 is the loopback address, the reserved network interface used by the local machine to allow interprocess communication so that it sends packets to itself. The ifconfig command uses the loopback address for configuration and testing, as explained in "ifconfig Command". Every machine on a TCP/IP network must use the IP address 127.0.0.1 for the local host.

Host Name

The IP address 192.9.200.3 and the name ahaggar are the address and host name of the local machine. They are assigned to the machine's primary network interface.

Multiple Network Interfaces

Some machines have more than one network interface, either because they are routers or multihomed hosts. Each additional network interface attached to the machine requires its own IP address and associated name. When you configure a router or multihomed host, you must manually add this information to the router's /etc/inet/hosts file. (See Chapter 5, Configuring Routers, for more information on setting up routers and multihomed hosts.)

Example 4-2 is the /etc/inet/hosts file for machine timbuktu shown in Figure 4-1.

Example 4-2 /etc/inet/hosts File for Machine timbuktu

127.0.0.1      localhost     loghost
192.9.200.70   timbuktu      #This is the local host name
192.9.201.10   timbuktu-201	#Interface to network 192.9.201

With these two interfaces, timbuktu connects networks 192.9.200 and 192.9.201 as a router.

How Name Services Affect the hosts Database

The NIS, NIS+, and DNS name services maintain host names and addresses on one or more servers. These servers maintain hosts databases containing information for every host and router (if applicable) on the servers' network. Refer to the Solaris Naming Administration Guide for more information about these services.

When Local Files Provide Name Service

On a network using local files for name service, machines running in local files mode consult their individual /etc/inet/hosts files for IP addresses and host names of other machines on the network. Therefore, their /etc/inet/hosts files must contain the:

• Loopback address

• IP address and host name of the local machine (primary network interface)

• IP address and host name of additional network interfaces attached to this machine, if applicable

• IP addresses and host names of all hosts on the local network

• IP addresses and host names of any routers this machine must know about, if applicable

• IP address of any machine your machine wants to refer to by its host name

Example 4-3 shows the /etc/inet/hosts file for machine tenere, a machine that runs in local files mode. Notice that the file contains the IP addresses and host names for every machine on the 192.9.200 network. It also contains the IP address and interface name timbuktu-201, which connects the 192.9.200 network to the 192.9.201 network.

A machine configured as a network client uses the local /etc/inet/hosts file for its loopback address and IP address.

Example 4-3 /etc/inet/hosts File for Machine Running in Local Files Mode

netmasks Database

You need to edit the netmasks database as part of network configuration only if you have set up subnetting on your network. The netmasks database consists of a list of networks and their associated subnet masks.

When you create subnets, each new network must be a separate physical network. You cannot apply subnetting to a single physical network.

What is Subnetting

Subnetting is a method for getting the most out of the limited 32-bit IP addressing space and reducing the size of the routing tables in a large internetwork. With any address class, subnetting provides a means of allocating a part of the host address space to network addresses, which lets you have more networks. The part of the host address space allocated to new network addresses is known as the subnet number.

In addition to making more efficient use of the IP address space, subnetting has several administrative benefits. Routing can become very complicated as the number of networks grows. A small organization, for example, might give each local network a class C number. As the organization grows, administering a number of different network numbers could become complicated. A better idea is to allocate a few class B network numbers to each major division in an organization. For instance, you could allocate one to Engineering, one to Operations, and so on. Then, you could divide each class B network into additional networks, using the additional network numbers gained by subnetting. This can also reduce the amount of routing information that must be communicated among routers.

Creating the Network Mask

As part of the subnetting process, you need to select a network-wide netmask. The netmask determines how many and which bits in the host address space represent the subnet number and how many and which represent the host number. Recall that the complete IP address consists of 32 bits. Depending on the address class, as many as 24 bits and as few as 8 bits can be available for representing the host address space. The netmask is specified in the netmasks database.

If you plan to use subnets, you must determine your netmask before you configure TCP/IP. You then need to carry out the procedures in "How to Add a Subnet to a Network". If you plan to install the operating system as part of network configuration, the Solaris installation program requests the netmask for your network.

As described in "Parts of the IP Address", 32-bit IP addresses consist of a network part and a host part. The 32 bits are divided into 4 bytes. Each byte is assigned either to the network number or the host number, depending on the network class.

For example, in a class B IP address, the 2 left-hand bytes are assigned to the network number, and the 2 right-hand bytes are assigned to the host number. In the class B IP address 129.144.41.10, you can assign the 2 right-hand bytes to hosts.

If you are going to implement subnetting, you need to use some of the bits in the bytes assigned to the host number to apply to subnet addresses. For example, a 16-bit host address space provides addressing for 65,534 hosts. If you apply the third byte to subnet addresses and the fourth to host addresses, you can address up to 254 networks, with up to 254 hosts on each.

The bits in the host address bytes that will be applied to subnet addresses and those applied to host addresses is determined by a subnet mask. Subnet masks are used to select bits from either byte for use as subnet addresses. Although netmask bits must be contiguous, they need not align on byte boundaries.

The netmask can be applied to an IP address using the bitwise logical AND operator. This operation selects out the network number and subnet number positions of the address.

It is easiest to explain netmasks in terms of their binary representation. You can use a calculator for binary-to-decimal conversion. The following examples show both the decimal and binary forms of the netmask.

If a netmask 255.255.255.0 is applied to the IP address 129.144.41.101, the result is the IP address of 129.144.41.0.

129.144.41.101 & 255.255.255.0 = 129.144.41.0

In binary form, the operation is:

10000001.10010000.00101001.01100101 (IP address)

ANDed with

11111111.11111111.11111111.00000000 (netmask)

Now the system looks for a network number of 129.144.41 instead of a network number of 129.144. If you have a network with the number 129.144.41, that is what the system looks for and finds. Since you can assign up to 254 values to the third byte of the IP address space, subnetting lets you create address space for 254 networks, where previously there was room for only one.

If you want to provide address space for only two additional networks, you could use a subnet mask of:

255.255.192.0

This netmask provides a result of:

11111111.11111111.1100000.00000000

This still leaves 14 bits available for host addresses. Since all 0s and 1s are reserved, at least two bits must be reserved for the host number.

Editing the /etc/inet/netmasks File

If your network runs NIS or NIS+, the servers for these name services maintain netmasks databases. For networks that use local files for name service, this information is maintained in the /etc/inet/netmasks file.

For compatibility with BSD-based operating systems, the file /etc/netmasks is a symbolic link to /etc/inet/netmasks.

Example 4-4 shows the /etc/inet/netmasks file for a class B network.

Example 4-4 /etc/inet/netmasks File for a Class B Network

## The netmasks file associates Internet Protocol (IP) address
 # masks with IP network numbers.
 #
 # 	network-number	netmask
 #
 # Both the network-number and the netmasks are specified in
 # "decimal dot" notation, e.g:
 #
 #        128.32.0.0   255.255.255.0
          129.144.0.0  255.255.255.0

If the file does not exist, create it. Use the following syntax:

network-number	netmask-number

Refer to the netmasks(4) man page for complete details.

When creating netmask numbers, type the network number assigned by the InterNIC (not the subnet number) and netmask number in /etc/inet/netmasks. Each subnet mask should be on a separate line.

For example:

128.78.0.0	    255.255.248.0

You can also type symbolic names for network numbers in the /etc/inet/hosts file. You can then use these network names instead of the network numbers as parameters to commands.

How to Add a Subnet to a Network

If you are changing from a network that does not use subnets to one that is subnetted, perform the following steps:

1. Decide on the new subnet topology, including considerations for routers and locations of hosts on the subnets.

2. Assign all subnet and host addresses.

3. Modify the /etc/inet/netmasks file, if you are manually configuring TCP/IP, or supply the netmask to the Solaris installation program.

4. Modify the /etc/inet/hosts files on all hosts to reflect the new host addresses.

5. Reboot all machines.

Network Databases and nsswitch.conf File

The network databases are files that provide information needed to configure the network. The network databases are:

• hosts

• netmasks

• ethers

• bootparams

• protocols

• services

• networks

As part of the configuration process, you edit the hosts database and the netmasks database, if your network is subnetted. Two network databases, bootparams and ethers, are used to configure machines as network clients. The remaining databases are used by the operating system and seldom require editing.

Although it is not a network database, the nsswitch.conf file needs to be configured along with the relevant network databases. nsswitch.conf specifies which name service to use for a particular machine: NIS, NIS+, DNS, or local files.

How Name Services Affect Network Databases

Your network database takes a form that depends on the type of name service you select for your network. For example, the hosts database contains, at minimum, the host name and IP address of the local machine and any network interfaces directly connected to the local machine. However, the hosts database could contain other IP addresses and host names, depending on the type of name service on your network.

The network databases are used as follows:

• Networks that use local files for their name service rely on files in the /etc/inet and /etc directories

• NIS+ uses databases called NIS+ tables

• NIS uses databases called NIS maps

• DNS uses records with host information

DNS boot and data files do not correspond directly to the network databases.

Figure 4-2 shows the forms of the hosts database used by these name services:

Figure 4-2 Forms of the hosts Database Used by Name Services

Table 4-1 lists the network databases and how they are used by local files, NIS+, and NIS.

This book discusses network databases as viewed by networks using local files for name services. Information regarding the hosts database is in "hosts Database"; information regarding the netmasks database is in "netmasks Database". Refer to Solaris Naming Administration Guide for information on network databases correspondences in NIS, DNS, and NIS+.

nsswitch.conf File -- Specifying Which Name Service to Use

The /etc/nsswitch.conf file defines the search order of the network databases. The Solaris installation program creates a default /etc/nsswitch.conf file for the local machine, based on the name service you indicate during the installation process. If you selected the "None" option, indicating local files for name service, the resulting nsswitch.conf file resembles Example 4-5.

Example 4-5 nsswitch.conf for Networks Using Files for Name Service

# /etc/nsswitch.files:
#
# An example file that could be copied over to /etc/nsswitch.conf;
# it does not use any naming service.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file contains "switch.so" as a
# nametoaddr library for "inet" transports.

passwd:          files
group:           files
hosts:           files
networks:        files
protocols:       files
rpc:             files
ethers:          files
netmasks:        files	
bootparams:      files
publickey:       files
# At present there isn't a 'files' backend for netgroup; the
# system will figure it out pretty quickly,
# and won't use netgroups at all.
netgroup:        files
automount:       files
aliases:         files
services:        files
sendmailvars:    files

The nsswitch.conf(4) man page describes the file in detail. Its basic syntax is:

database name-service-to-search

The database field can list one of many types of databases searched by the operating system. For example, it could indicate a database affecting users, such as passwd or aliases, or a network database. The parameter name-service-to-search can have the values files, nis, or nis+ for the network databases. (The hosts database can also have dns as a name service to search.) You can also list more than one name service, such as nis+ and files.

In Example 4-5, the only search option indicated is files. Therefore, the local machine gets security and automounting information, in addition to network database information, from files located in its /etc and /etc/inet directories.

Changing nsswitch.conf

The /etc directory contains the nsswitch.conf file created by the Solaris installation program. It also contains template files for the following name services:

• nsswitch.files

• nsswitch.nis

• nsswitch.nis+

If you want to change from one name service to another, you can copy the appropriate template to nsswitch.conf. You can also selectively edit the nsswitch.conf file, and change the default name service to search for individual databases.

For example, on a network running NIS, you might have to change the nsswitch.conf file on diskless clients. The search path for the bootparams and ethers databases must list files as the first option, and nis. Example 4-6 shows the correct search paths.

Example 4-6 nsswitch.conf for a Diskless Client on a Network Running NIS

## /etc/nsswitch.conf:#
.
.
passwd:        files nis
group:         file nis

# consult /etc "files" only if nis is down.
hosts:         nis    [NOTFOUND=return] files
networks:      nis    [NOTFOUND=return] files
protocols:     nis    [NOTFOUND=return] files
rpc:           nis    [NOTFOUND=return] files
ethers:        files  [NOTFOUND=return] nis
netmasks:      nis    [NOTFOUND=return] files	
bootparams:    files  [NOTFOUND=return] nis
publickey:     nis    netgroup:         nis

automount:     files nis
aliases:       files nis

# for efficient getservbyname() avoid nis
services:      files nis
sendmailvars:  files

For complete details on the name service switch, refer to Solaris Naming Administration Guide.

bootparams Database

The bootparams database contains information used by diskless clients and machines configured to boot in the network client mode. You need to edit it if your network will have network clients. (See "Configuring Network Clients" for procedures.) The database is built from information entered into the /etc/bootparams file.

The bootparams(4) man page contains complete syntax for this database. Its basic syntax is

machine-name file-key-server-name:pathname

For each diskless or network client machine, the entry might contain the following information: the name of the client, a list of keys, the names of servers, and path names.

The first item of each entry is the name of the client machine. Next is a list of keys, names of servers, and path names, separated by tab characters. All items but the first are optional. The database can contain a wildcard entry that will be matched by all clients. Here is an example:

Example 4-7 bootparams Database

myclient   root=myserver : /nfsroot/myclient  \
swap=myserver : /nfsswap//myclient \
dump=myserver : /nfsdump/myclient

In this example the term dump=: tells diskless hosts not to look for a dump file.

Wildcard Entry for bootparams

In most cases, you will want to use the wildcard entry when editing the bootparams database to support diskless clients. This entry is:

*  root=server:/path dump=:

The asterisk (*) wildcard indicates that this entry applies to all clients not specifically named within the bootparams database.

ethers Database

The ethers database is built from information entered into the /etc/ethers file. It associates host names to their Ethernet addresses. You need to create an ethers database only if you are running the RARP daemon; that is, if you are configuring network clients or diskless machines.

RARP uses the file to map Ethernet addresses to IP addresses. If you are running the RARP daemon in.rarpd, you need to set up the ethers file and maintain it on all hosts running the daemon to reflect changes to the network.

The ethers(4) man page contains complete syntax information for this database. Its basic format is:

Ethernet-address hostname #comment

Ethernet-address is the Ethernet address of the host.

hostname is the official name of the host.

#comment is any kind of note you want to append to an entry in the file.

The equipment manufacturer provides the Ethernet address. If a machine does not display the Ethernet address when you power up, see your hardware manuals for assistance.

When adding entries to the ethers database, make sure that host names correspond to the primary names in the hosts database, not to the nicknames, as shown in Example 4-8.

Example 4-8 Entries in the ethers Database

8:0:20:1:40:16  fayoum
8:0:20:1:40:15  nubian 
8:0:20:1:40:7   sahara    # This is a comment
8:0:20:1:40:14  tenere 

Other Network Databases

The remaining network databases seldom need to be edited.

networks database

The networks database associates network names with network numbers, enabling some applications to use and display names rather than numbers. The networks database is based on information in the /etc/inet/networks file. It contains the names of all networks to which your network connects via routers.

The Solaris installation program sets up the initial networks database. The only time you need to update it is when you add a new network to your existing network topology.

The networks(4) man page contains full syntax information for /etc/inet/networks. Here is its basic format

network-name network-number nickname(s) # comment

network-name is the official name for the network.

network-number is the number assigned by the InterNIC.

nickname is any other name by which the network is known.

#comment is any kind of note you want to append to an entry in the file.

It is particularly important that you maintain the networks file. The netstat program uses the information in this database to produce status tables.

Example 4-9 shows a sample /etc/networks file:

Example 4-9 /etc/networks File

#ident	"@(#)networks	1.4	92/07/14 SMI"	/* SVr4.0 1.1	*/
#
# The networks file associates Internet Protocol (IP) network
numbers with network names. The format of this file is:
#
# 	network-name		 	 network-number		 	 nicnames . . .

# The loopback network is used only for intra-machine
communication
#loopback		 	 127

# Internet networks
#
arpanet     10	   arpa  # Historical
ucb-ether   46	   ucbether
#
# local networks

eng   193.9.0  #engineering
acc   193.9.1  #accounting
prog  193.9.2  #programming

protocols Database

The protocols database lists the TCP/IP protocols installed on your system and their numbers; the Solaris installation program automatically creates it. It is rare when this file requires administrative handling.

The protocols database contains the names of the TCP/IP protocols installed on the system. Its syntax is completely described in the protocols(4) man page. Example 4-10 shows an example of the /etc/inet/protocols file:

Example 4-10 /etc/inet/protocols File

#
# Internet (IP) protocols
#
ip    0   IP    # internet protocol, pseudo protocol number
icmp  1   ICMP  # internet control message protocol
tcp   6   TCP   # transmission control protocol
udp  17   UDP   # user datagram protocol

services Database

The services database lists the names of TCP and UDP services and their well known port numbers; it is used by programs that call network services. The Solaris installation automatically creates the services database; it generally requires no administrative handling.

The services(4) man page contains complete syntax information. Example 4-11 shows an excerpt from a typical /etc/inet/services file:

Example 4-11 /etc/inet/services File

#
# Network services
#
echo      7/udp
echo      7/tcp
discard   9/udp     sink null
discard   11/tcp
daytime   13/udp
daytime   13/tcp
netstat   15/tcp
ftp-data  20/tcp
ftp       21/tcp
telnet    23/tcp
time      37/tcp    timeserver
time      37/udp    timeserver
name      42/udp    nameserver
whois     43/tcp    nickname

Network Configuration Procedures

Network software installation takes place along with the installation of the operating system software. At that time, certain IP configuration parameters must be stored in appropriate files so they can be read at boot time.

The procedure is simply a matter of creating or editing the network- configuration files. How configuration information is made available to a machine's kernel depends on whether these files are stored locally (local files mode) or acquired from the network configuration server (network client mode).

Parameters supplied during network configuration are:

• IP address of each network interface on every machine

• Host names of each machine on the network. You can type the host name in a local file or a name service database.

• NIS, NIS+, or DNS domain name in which the machine resides, if applicable

• Default router addresses. You supply this only if you have a simple network topology with only one router attached to each network, or your routers don't run routing protocols such as the Router Discovery Server Protocol (RDISC) or the Router Information Protocol (RIP). (See Chapter 5, Configuring Routers, for more information about these protocols.)

• Subnet mask (required only for networks with subnets)

This chapter contains complete information on creating and editing local configuration files. See the Solaris Naming Administration Guide for information on working with name service databases.

How to Configure a Host for Local Files Mode

Use this procedure for configuring TCP/IP on a machine that run in local files mode.

1. Become superuser and change to the /etc directory.

2. Type the host name of the machine in the file /etc/nodename.

   For example, if the name of the host is tenere, type tenere in the file.

3. Create a file named /etc/hostname.interface for each network interface.

   (The Solaris installation program automatically creates this file for the primary network interface.)

   Refer to "/etc/hostname.interface File" for complete details.

4. Type either the interface IP address or the interface name in each /etc/hostname.interface file.

   For example, create a file named hostname.ie1, and type either the IP address of the host's interface or the host's name.

5. Edit the /etc/inet/hosts file to add:

   1. IP addresses that you have assigned to any additional network interfaces in the local machine, along with the corresponding host name for each interface.

      The Solaris installation program will already have created entries for the primary network interface and loopback address.

   2. IP address or addresses of the file server, if the /usr file system is NFS mounted.

      ---

      Note -

      The Solaris installation program creates the default /etc/inet/hosts for the local machine. If the file does not exist, create it as shown in "hosts Database".

      ---

6. Type the host's fully qualified domain name in the /etc/defaultdomain file.

   For example, suppose host tenere was part of the domain deserts.worldwide.com. Therefore, you would type: deserts.worldwide.com in /etc/defaultdomain. See "/etc/defaultdomain File" for more information.

7. Type the router's name in /etc/defaultrouter.

   See "/etc/defaultrouter File" for information about this file.

8. Type the name of the default router and its IP addresses in /etc/inet/hosts.

   Additional routing options are available. Refer to the discussion on routing options in "How to Configure Hosts for Network Client Mode". You can apply these options to a local files mode configuration.

9. If your network is subnetted, type the network number and the netmask in the file /etc/inet/netmasks.

   If you have set up a NIS or NIS+ server, you can type netmask information in the appropriate database on the server as long as server and clients are on the same network.

10. Reboot each machine on the network.

Setting Up a Network Configuration Server

If you plan to configure certain hosts as network clients, you must configure at least one machine on your network as a network configuration server. (Refer to "Network Configuration Servers" for an introduction.)

Setting up a network configuration server involves:

1. Turning on the network configuration daemons:

   • in.tftpd

   • in.rarpd

   • rpc.bootparamd

2. Editing and maintaining the network configuration files on the configuration server.

   "How to Set Up a Network Configuration Server" assumes that you have already set up the network configuration server for local files mode.

How to Set Up a Network Configuration Server

1. Become superuser and change to the root directory of the prospective network configuration server.

2. Turn on the in.tftpd daemon by creating the directory /tftpboot:

   # mkdir /tftpboot

   This configures the machine as a TFTP, bootparams, and RARP server.

3. Create a symbolic link to the directory.

   # ln -s /tftpboot/. /tftpboot/tftpboot

4. Enable the tftp line in intetd.conf.

   Check that the /etc/inetd.conf entry reads:

   tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot

   This prevents inettftpd() from retrieving any file other than one located in /tftpboot.

5. Edit the hosts database, and add the host names and IP addresses for every client on the network.

6. Edit the ethers database, and create entries for every host on the network to run in network client mode.

7. Edit the bootparams database.

   See "bootparams Database". Use the wildcard entry or create an entry for every host that run in network client mode.

8. Reboot the server.

Information for setting up diskless clients, install servers, and boot servers can be found in Solaris Advanced Installation Guide.

Configuring Network Clients

Network clients receive their configuration information from network configuration servers. Therefore, before you configure a host as a network client you must ensure that at least one network configuration server is set up for the network.

How to Configure Hosts for Network Client Mode

Do the following on each host to be configured in network client mode:

1. Become superuser.

2. Check the directory for the existence of an /etc/nodename file. If one exists, delete it.

   Eliminating /etc/nodename causes the system to use the hostconfig program to obtain the host name, domain name, and router addresses from the network configuration server. See "Network Configuration Procedures".

3. Create the file /etc/hostname.interface, if it does not exist.

   Make sure that the file is empty. An empty /etc/hostname.interface file causes the system to acquire the IP address from the network configuration server.

4. Ensure that the /etc/inet/hosts file contains only the host name and IP address of the loopback network interface.

   (See "Loopback Address".) The file should not contain the IP address and host name for the local machine (primary network interface).

   EXCEPTION: For a diskless client (a machine with an NFS-mounted root file system), type the name and IP address of the server that provides the client's root file system (usually, but not always, the network configuration server).

5. Check for the existence of an /etc/defaultdomain file. If one exists, delete it.

   The hostconfig program sets the domain name automatically. If you want to override the domain name set by hostconfig, type the substitute domain name in the file /etc/defaultdomain.

6. Ensure that the search paths in the client's /etc/nsswitch.conf reflects the name service requirements for your network.

How to Specify a Router for the Network Client

1. If you have only one router on the network and you want the network configuration server to specify its name automatically, ensure that the network client does not have a /etc/defaultrouter file.

2. To override the name of the default router provided by the network configuration server:

   1. Create /etc/defaultrouter on the network client.

   2. Type the host name and IP address of the machine you have designated as the default router.

   3. Add the host name and IP address of the designated default router to the network client's /etc/inet/hosts.

3. If you have multiple routers on the network, create /etc/defaultrouter on the network client, but leave it empty.

Creating /etc/defaultrouter and leaving it empty causes one of the two dynamic routing protocols to run: ICMP Router Discovery protocol (RDISC), or Routing Information Protocol (RIP). The system first runs the program in.rdisc, which looks for routers that are running the router discovery protocol. If it finds one such router, in.rdisc continues to run and keeps track of the routers that are running the RDISC protocol.

If the system discovers that routers are not responding to the RDISC protocol, it uses RIP and runs the daemon in.routed to keep track of them.

After Installing a Network Client

After you have finished editing the files on each network client machine, do the following on the network configuration server.

1. Add entries for the hosts in the ethers and hosts databases.

2. Add entries for the hosts to the bootparams database.

   To simplify matters, you can type a wild card in the bootparams database in place of individual entries for each host. For an example, see "bootparams Database".

3. Reboot the server.

Configuring Standard TCP/IP Services

Services such as telnet, ftp, and rlogin are started by the inetd daemon, which runs automatically at boot time. Like the name service ordering specified in nsswitch.conf, you can configure TCP/IP services in the file /etc/inetd.conf by using the inetd -t flag.

For example, you can use inetd to log the IP addresses of all incoming TCP connections (remote logins and telnet). To turn the logging on, kill the running inetd and type:

# /usr/sbin/inetd -t -s

The t switch turns on TCP connection-tracing in inetd.

Refer to the inetd(1M) and inetd.conf(4) man pages.

See Solaris Naming Administration Guide and Solaris Naming Setup and Configuration Guide for further information on name services.

Overview of the Booting Processes

The following information is provided for your reference. It is a brief overview of the network booting processes to help you better visualize what is happening during configuration.

The names of startup scripts might change from one release to another.

1. You start the operating system on a host.

2. The kernel runs /sbin/init, as part of the booting process.

3. /sbin/init runs the /etc/rcS.d/S30rootusr.sh. startup script.

4. The script runs a number of system startup tasks, including establishing the minimum host and network configurations for diskless and dataless operations. /etc/rcS.d/S30rootusr.sh also mounts the /usr file system.

   1. If the local database files contain the required configuration information (host name and IP address), the script uses it.

   2. If the information is not available in local host configuration files, /etc/rcS.d/S30rootusr.sh uses RARP to acquire the host's IP address.

5. If the local files contain domain name, host name, and default router address, the machine uses them. If the configuration information is not in local files, then the system uses the Bootparams protocol to acquire the host name, domain name, and default router address. Note that the required information must be available on a network configuration server that is located on the same network as the host. This is necessary because no internetwork communications exist at this point.

6. After /etc/rcS/S30rootusr.sh completes its tasks and several other boot procedures have executed, /etc/rc2.d/S69inet runs. This script executes startup tasks that must be completed before the name services (NIS, NIS+, or DNS) can start. These tasks include configuring the IP routing and setting the domain name.

7. At completion of the S69inet tasks, /etc/rc2.d/S71rpc runs. This script starts the NIS, NIS+, or DNS name service.

8. After /etc/rc2.d/S71 runs, /etc/rc2.d/S72inetsvc runs. This script starts up services that depend on the presence of the name services. S72inetsvc also starts the daemon inetd, which manages user services such as telnet.

See System Administration Guide for a complete description of the booting process.

Chapter 5 Configuring Routers

This chapter describes routing protocols and contains procedures specifically for configuring routers on TCP/IP networks. A router is any machine that has two or more network interfaces and forwards packets from one network to another. Two common types of routers are computers with additional network interfaces in their card slots and dedicated routers sold by various manufacturers.

This chapter does not explain the theory of routing. You can find that information in "Network Topology"; "How Routers Transfer Packets" explains basic topics regarding routing. Tasks for creating subnets are found in "netmasks Database".

• "Routing Protocols"

• "How to Configure a Machine as a Router"

• "Creating a Multihomed Host"

Routing Protocols

Solaris system software supports two routing protocols: Routing Information Protocol (RIP) and ICMP Router Discovery (RDISC). RIP and RDISC are both standard TCP/IP protocols.

Routing Information Protocol (RIP)

RIP is implemented by in.routed, the routing daemon, which automatically starts when the machine boots. When run on a router with the s option specified, in.routed fills the kernel routing table with a route to every reachable network and advertises "reachability" through all network interfaces.

When run on a host with the q option specified, in.routed extracts routing information but does not advertise reachability. On hosts, routing information can be extracted in two ways:

• Do not specify the S flag (capital "S": "Space-saving mode") and in.routed builds a full routing table exactly as it does on a router.

• Specify the S flag and in.routed creates a minimal kernel table, containing a single default route for each available router.

ICMP Router Discovery (RDISC) Protocol

Hosts used RDISC to obtain routing information from routers. Thus, when hosts are running RDISC, routers must also run another protocol, such as RIP, in order to exchange router information among themselves.

RDISC is implemented by in.rdisc, which should run on both routers and hosts. Normally, when in.rdisc runs on a host, it enters a default route for each router that is also running in.rdisc. A host that is running in.rdisc can not discover routers that are running only RIP. Furthermore, when routers are running in.rdisc (rather than in.routed), they can be configured to have a different preference, which causes hosts to select a better router. See the rdisc(1M) man page.

Configuring Routers

TCP/IP's first requirement for a router is that the machine must have at least two network interfaces installed, as introduced in "Network Interfaces". As long as one of the network interfaces is not disabled, the router automatically "talks" to the RDISC and RIP protocols. These protocols keep track of routers on the network and advertise the router to the hosts on the network.

After the router is physically installed on the network, configure it to operate in local files mode, as described in "How to Configure a Host for Local Files Mode". This ensures that routers will boot in case the network configuration server is down. Remember that,unlike a host, a router has at least two interfaces to configure.

Configuring Both Router Network Interfaces

Because a router provides the interface between two or more networks, you must assign a unique name and IP address to each of the router's network interface cards. Thus, each router has a host name and IP address associated with its primary network interface, plus at least one more unique name and IP address for each additional network interface.

How to Configure a Machine as a Router

Become superuser on the machine to be configured as a router and do the following:

1. Create an /etc/hostname.interface file or each network interface installed.

   For example, create hostname.ie0 and hostname.ie1. (See "/etc/hostname.interface File" for more information.)

2. Type in each file the host name you have selected for that interface.

   For example, you could type the name timbuktu in the file hostname.ie0, then type the name timbuktu-201 in the file hostname.ie1. Both interfaces would be located on the same machine.

3. Type the host name and IP address of each interface into /etc/inet/hosts.

   For example:

   192.9.200.20 timbuktu #interface for network 192.9.200 192.9.201.20 timbuktu-201 #interface for network 192.9.201 192.9.200.9 gobi 192.9.200.10 mojave 192.9.200.110 saltlake 192.9.200.12 chilean

   The interfaces timbuktu and timbuktu-201 are on the same machine. Notice that the network address for timbuktu-201 is different from that of timbuktu. That is because the medium for network 192.9.201 is connected to the timbuktu-201 network interface while the media for network 192.9.200 is connected to the timbuktu interface.

4. If the router is connected to any subnetted network, edit /etc/inet/netmasks and type the local network number (129.9.0.0, for example) and associated netmask number (255.255.255.0, for example).

How a Machine Determinesif it is a Router

The /etc/rc2.d/S69inet startup script, which runs when the machine boots, determines whether a machine is a router or a host. This decision also determines whether the routing protocols (RIP and RDISC) should run in router mode or host mode.

The /etc/rc2.d/S69inet script concludes that a machine is a router if the following two conditions exist:

• More than one /etc/hostname.interface file exists.

• More than one interface was configured "up" by the ifconfig command. (See the ifconfig(1M) man page.)

If only one interface is found, the script concludes that the machine is a host. See "Configuring Both Router Network Interfaces". An interface that is configured by any means other than an /etc/hostname.interface file is not taken into account.

Automatic Routing Protocol Selection

The startup script then must determine whether to start up a routing protocol (RIP or RDISC) on the machine or use static routing.

To Select Static Routing on a Host

If the host is a diskless client or network client, add an entry for a router on the network into /etc/defaultrouter. (See "/etc/defaultrouter File".) A single static default route is then installed in the routing table. Under this condition, the host does not run any dynamic routing protocol (such as RIP and RDISC).

To Select Dynamic Routing on a Host

To force a diskless client or network client to select a dynamic routing protocol, its /etc/defaultrouter file should be empty. The type of dynamic routing used is selected according to the following criteria:

• If the /usr/sbin/in.rdisc program exists, the startup script starts in.rdisc. Any router on the network that is running RDISC then responds to any RDISC queries from the host. If at least one router responds, the host selects RDISC as its routing protocol.

• If the network router is not running RDISC or fails to respond to the RDISC queries, then in.rdisc on the host exits. The host then starts in.routed, which runs RIP.

Forcing a Machine to Be a Router

You can force a machine that has only one /etc/hostname.interface file (by default a host) to be a router. To do so, create a file named /etc/gateways and leave it empty. This is important if you decide to configure PPP links, as explained in "Routing Considerations".

Creating a Multihomed Host

By default, TCP/IP considers any machine with multiple network interfaces to be a router. However, you can change a router into a multihomed host--a machine with more than one network interface that does not run routing protocols or forward IP packets. You typically configure the following types of machines as multihomed hosts:

• NFS servers, particularly large data centers, can be attached to more than one network in order to share files among a large pool of users. These servers don't need to maintain routing tables.

• Database servers can have multiple network interfaces for the same reason as NFS servers--to provide resources to a large pool of users.

• Firewall gateways are machines that provide the connection between a company's network and public networks such as the Internet. Administrators set up firewalls as a security measure. When configured as a firewall, the host will not pass packets between the networks attached to it. On the other hand, it can still provide standard TCP/IP services, such as ftp or rlogin, to authorized users.

Since TCP/IP considers any machine with multiple network interfaces to be a router, you need to perform a few operations to turn it into a multihomed host.

How to Create a Multihomed Host

Become superuser on the prospective multihomed host and do the following:

1. Create an /etc/hostname.interface file for each additional network interface installed in the machine.

2. Type:

   % touch /etc/notrouter

   This creates an empty file called /etc/notrouter.

3. Reboot the machine.

When the machine reboots, the startup script looks for the presence of the /etc/notrouter file. If the file exists, the startup script does not run in.routed -s or in.rdisc -r, and does not turn on IP forwarding on all interfaces configured "up" by ifconfig. This happens regardless of whether an /etc/gateways file exists. Thus the machine is now a multihomed host.

Turning On Space-Saving Mode

Space-saving mode provides the host with a table that contains only the default routes. On a host, in.routed runs with space saving mode turned off by default.

If you do not want the host to have a full routing table (which provides increased protection against misconfigured routers), turn space saving mode on. To do so, edit the /etc/rc2.d/S69inet startup script by changing the line:

/usr/sbin/in.routed -q

to

/usr/sbin/in.routed -q -S

Turning Off ICMP Router Discovery on the Host

For reasons involving router reliability, you might not want your hosts to use RDISC. To turn RDISC off, change the name of the host's /usr/sbin/in.rdisc to some other name, such as /usr/sbin/in.rdisc.saved, and then reboot the host.

Turning Off ICMP Router Discovery on the Router

If the automatic selection of RIP rather than RDISC by a host is to work reliably, the routers in the network (particularly those running RDISC) must also work reliably.

If your routers are not running RDISC and you install a single Solaris router, by default all hosts connected to that router rely on it alone. To have the hosts on that network use the other routers as well, turn off RDISC on the new router. To do this, change the name of the router's /usr/bin/in.rdisc file to some other file name and reboot the router.

Chapter 6 Troubleshooting TCP/IP

This chapter describes general methods for troubleshooting TCP/IP networks and some of the tools available for doing so. These tools include ping, ifconfig, netstat, and route.

• "General Troubleshooting Methods"

• "Running Software Checks"

• "ping Command"

• "ifconfig Command"

• "netstat Command"

• "Logging Network Problems"

• "Displaying Packet Contents"

General Troubleshooting Methods

One of the first signs of trouble on the network is a loss of communications by one or more hosts. If a host refuses to come up at all the first time it is added to the network, the problem might lie in one of the configuration files, or in the network interface. If a single host suddenly develops a problem, the network interface might be the cause. If the hosts on a network can communicate with each other but not with other networks, the problem could lie with the router, or it could lie in another network.

You can use the ifconfig program to obtain information on network interfaces and netstat to display routing tables and protocol statistics. Third-party network diagnostic programs provide a number of troubleshooting utilities. Refer to third-party documentation for information.

Less obvious are the causes of problems that degrade performance on the network. For example, you can use tools like ping to quantify problems like the loss of packets by a host.

Running Software Checks

If there is trouble on the network, some actions that you can take to diagnose and fix software-related problems include:

1. Using the netstat command to display network information.

2. Checking the hosts database to make sure that the entries are correct and up to date.

3. If you are running RARP, checking the Ethernet addresses in the ethers database to make sure that the entries are correct and up to date.

4. Trying to connect by telnet to the local host.

5. Ensuring that the network daemon inetd is running. To do this, log in as superuser and type:

   # ps -ef | grep inetd

Here is an example of output displayed if the inetd daemon is running:

root 57 1 0 Apr 04 ? 3:19 /usr/sbin/inetd -s
root 4218 4198 0 17:57:23 pts/3 0:00 grep inetd 

ping Command

Use the ping command to find out whether there is IP connectivity to a particular host. The basic syntax is:

/usr/sbin/ping host [timeout]

where host is the host name of the machine in question. The optional timeout argument indicates the time in seconds for ping to keep trying to reach the machine--20 seconds by default. The ping(1M) man page describes additional syntaxes and options.

When you run ping, the ICMP protocol sends a datagram to the host you specify, asking for a response. (ICMP is the protocol responsible for error handling on a TCP/IP network. See "ICMP Protocol" for details.)

Suppose you type:

$ ping elvis

If host elvis is up, this message is displayed:

elvis is alive

indicating that elvis responded to the ICMP request. However, if elvis is down or cannot receive the ICMP packets, you receive the following response from ping:

no answer from elvis

If you suspect that a machine might be losing packets even though it is up, you can use the s option of ping to try to detect the problem. For example, type:

$ ping -s elvis 

ping continually sends packets to elvis until you send an interrupt character or a timeout occurs. The responses on your screen will resemble:

PING elvis: 56 data bytes
64 bytes from 129.144.50.21: icmp_seq=0. time=80. ms
64 bytes from 129.144.50.21: icmp_seq=1. time=0. ms
64 bytes from 129.144.50.21: icmp_seq=2. time=0. ms
64 bytes from 129.144.50.21: icmp_seq=3. time=0. ms
.
.
.
----elvis PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/20/80   

The packet-loss statistic indicates whether the host has dropped packets.

If ping fails, check the status of the network reported by ifconfig and netstat, as described in "ifconfig Command" and "netstat Command".

ifconfig Command

The ifconfig command displays information about the configuration of an interface that you specify. (Refer to the ifconfig(1M) man page for complete details.) The syntax of ifconfig is:

ifconfig interface-name [protocol_family]

If you want information about a specific interface, for example le0, type:

$ ifconfig le0

For an le0 interface, your output resembles the following:

le0: flags=863<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
 	inet 129.144.44.140 netmask ffffff00 broadcast 129.144.44.255
ether 8:0:20:8:el:fd

The flags section just given shows that the interface is configured "up," capable of broadcasting, and not using "trailer" link level encapsulation. The mtu field tells you that this interface has a maximum transfer rate of 1500. Information on the second line includes the IP address of the host you are using, the netmask being currently used, and the IP broadcast address of the interface. The third line gives the machine address (Ethernet, in this case) of the host.

A useful ifconfig option is -a, which provides information on all interfaces on your network. For example, typing ifconfig -aproduces:

le0:  flags=49<UP,LOOPBACK,RUNNING> mtu 8232
     inet 127.144.44.140 netmask ff000000 
le0:flags=863<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
     inet 129.144.44.140 netmask ffffff00 broadcast 129.144.44.255
ether 8:0:20:8:el:fd

Output that indicates an interface is not running might mean a problem with that interface. In this case, see the ifconfig(1M) man page.

netstat Command

The netstat command generates displays that show network status and protocol statistics. You can display the status of TCP and UDP endpoints in table format, routing table information, and interface information.

netstat displays various types of network data depending on the command line option selected. These displays are the most useful for system administration. The syntax for this form is:

netstat [-m] [-n] [-s] [-i | -r] [-f address_family]

The most frequently used options for determining network status are: s, r, and i. See the netstat(1M) man page for a description of the options.

Displaying Per Protocol Statistics

The netstat -s option displays per protocol statistics for the UDP, TCP, ICMP, and IP protocols. The result resembles the display shown in the example below. (Parts of the output have been truncated.) The information can indicate areas where a protocol is having problems. For example, statistical information from ICMP can indicate where this protocol has found errors.

UDP
 
      udpInDatagrams      =  39228     udpOutDatagrams     =  2455  
      udpInErrors         =     0
 
TCP
 
      tcpRtoAlgorithm     =     4      tcpMaxConn          =    -1
      tcpRtoMax           = 60000      tcpPassiveOpens     =     2
      tcpActiveOpens      =     4      tcpEstabResets      =     1
      tcpAttemptFails     =     3      tcpOutSegs          =   315
      tcpCurrEstab        =     1      tcpOutDataBytes     = 10547
      tcpOutDataSegs      =   288      tcpRetransBytes     =  8376
      tcpRetransSegs      =    29      tcpOutAckDelayed    =    23
      tcpOutAck           =    27      tcpOutWinUpdate     =     2
      tcpOutUrg           =     2      tcpOutControl       =     8
      tcpOutWinProbe      =     0      tcpOutFastRetrans   =     1
      tcpOutRsts          =     0
      tcpInSegs           =   563      tcpInAckBytes       = 10549
      tcpInAckSegs        =   289      tcpInAckUnsent      =     0
      tcpInDupAck         =    27      tcpInInorderBytes   =   673
      tcpInInorderSegs    =   254      tcpInInorderBytes   =   673
      tcpInUnorderSegs    =     0      tcpInUnorderBytes   =     0
      tcpInDupSegs        =     0      tcpInDupBytes       =     0
      tcpInPartDupSegs    =     0      tcpInPartDupBytes   =     0
      tcpInPastWinSegs    =     0      tcpInPastWinBytes   =     0
      tcpInWinProbe       =     0      tcpInWinUpdate      =   237    
      tcpInClosed         =     0      tcpRttNoUpdate      =    21
      tcpRttUpdate        =   266      tcpTimRetrans       =    26
      tcpTimRetransDrop   =     0      tcpTimKeepalive     =     0
      tcpTimKeepaliveProbe=     0      tcpTimKeepaliveDrop =     0
 
IP
 
      ipForwarding        =     2      ipDefaultTTL        =   255
      ipInReceives        =  4518      ipInHdrErrors       =     0
      ipInAddrErrors      =     0      ipInCksumErrs       =     0
      ipForwDatagrams     =     0      ipForwProhibits     =     0
      ipInUnknownProtos   =     0      ipInDiscards        =     0
      ipInDelivers        =  4486      ipOutRequests       =  2805
      ipOutDiscards       =     5      ipOutNoRoutes       =     0
      ipReasmTimeout      =    60      ipReasmReqds        =     2
      ipReasmOKs          =     2      ipReasmReqds        =     2
      ipReasmDuplicates   =     0      ipReasmFails        =     0
      ipFragOKs           =    20      ipReasmPartDups     =     0
      ipFragCreates       =   116      ipFragFails         =     0
      tcpInErrs           =     0      ipRoutingDiscards   =     0
      udpInCksumErrs      =     0      udpNoPorts          =    33
      rawipInOverflows    =     0      udpInOverflows      =     6
 
ICMP
 
      icmpInMsgs          =     0      icmpInErrors        =     0
      icmpInCksumErrs     =     0      icmpInUnknowns      =     0
      icmpInDestUnreachs  =     0      icmpInTimeExcds     =     0
      icmpInParmProbs     =     0      icmpInSrcQuenchs    =     0
      icmpInRedirects     =     0      icmpInBadRedirects  =     0
      icmpInEchos         =     0      icmpInEchoReps      =     0
      icmpInTimestamps    =     0      icmpInTimestampReps =     0     
      icmpInAddrMasks     =     0      icmpInAddrMaskReps  =     0
      icmpInFragNeeded    =     0      icmpOutMsgs         =     7
      icmpOutDestUnreachs =     1      icmpOutErrors       =     0
      icmpOutDrops        =     5      icmpOutTimeExcds    =     0
      icmpOutParmProbs    =     0      icmpOutSrcQuenchs   =     6
      icmpOutRedirects    =     0      icmpOutEchos        =     0
      icmpOutEchoReps     =     0      icmpOutTimestamps   =     0
      icmpOutTimestampReps=     0      icmpOutAddrMasks    =     0
      icmpOutAddrMaskReps =     0      icmpOutFragNeeded   =     0
      icmpInOverflows     =     0

 
IGMP:
 
0 messages received
0 messages received with too few bytes
0 messages received with bad checksum
0 membership queries received
0 membership queries received with invalid field(s)
0 membership reports received
0 membership reports received with invalid field(s)
0 membership reports received for groups to which we belong
0 membership reports sent

Displaying Network Interface Status

The i option of netstat shows the state of the network interfaces that are configured with the machine where you ran the command. Here is a sample display produced by netstat -i.

 
Name Mtu  Net/Dest     Address   Ipkts    Ierrs Opkts    Oerrs  Collis  Queue
le0  1500 b5-spd-2f-cm tatra     14093893 8492  10174659 1119   2314178   0
lo0  8232 loopback     localhost 92997622 5442  12451748 0      775125    0

Using this display, you can find out how many packets a machine thinks it has transmitted and received on each network. For example, the input packet count (Ipkts) displayed for a server can increase each time a client tries to boot, while the output packet count (Opkts) remains steady. This suggests that the server is seeing the boot request packets from the client, but does not realize it is supposed to respond to them. This might be caused by an incorrect address in the hosts or ethers database.

On the other hand, if the input packet count is steady over time, it means that the machine does not see the packets at all. This suggests a different type of failure, possibly a hardware problem.

Displaying Routing Table Status

The -r option of netstat displays the IP routing table. Here is a sample display produced by netstat -r run on machine tenere.

Routing tables
Destination   Gateway Flags Refcnt Use   Interface
temp8milptp   elvis   UGH   0      0	
irmcpeb1-ptp0 elvis   UGH   0      0	
route93-ptp0  speed   UGH   0      0	
mtvb9-ptp0    speed   UGH   0      0	
	              .
mtnside       speed   UG    1      567	
ray-net       speed   UG    0      0	
mtnside-eng   speed   UG    0      36	
mtnside-eng   speed   UG    0      558	
mtnside-eng   tenere  U     33     190248  le0

The first column shows the destination network, the second the router through which packets are forwarded. The U flag indicates that the route is up; the G flag indicates that the route is to a gateway. The H flag indicates that the destination is a fully qualified host address, rather than a network.

The Refcnt column shows the number of active uses per route, and the Use column shows the number of packets sent per route. Finally, the Interface column shows the network interface that the route uses.

Logging Network Problems

If you suspect a routing daemon malfunction, you can log its actions, including all packet transfers. To create a log file of routing daemon actions, supply a file name when you start up the routed daemon. For example:

# /usr/sbin/in.routed /var/routerlog

On a busy network, this can generate almost continuous output.

Displaying Packet Contents

You can use snoop to capture network packets and display their contents. Packets can be displayed as soon as they are received, or saved to a file. When snoop writes to an intermediate file, packet loss under busy trace conditions is unlikely. snoop itself is then used to interpret the file. For information about using the snoop command, refer to the snoop(1M) man page.

The snoop command must be run by root (#) to capture packets to and from the default interface in promiscuous mode. In summary form, only the data pertaining to the highest-level protocol is displayed. For example, an NFS packet will have only NFS information displayed. The underlying RPC, UDP, IP, and Ethernet frame information is suppressed but can be displayed if either of the verbose options is chosen.

The snoop capture file format is described in RFC 1761. To access, use your favorite web browser with the URL: http://ds.internic.net/rfc/rfc1761.txt.

snoop server client rpc rstatd collects all RPC traffic between a client and server, and filters it for rstatd.

How to check all packets from your system

1. Type netstat -i to find the interfaces attached to the system.

   Snoop normally uses the first non-loopback device (le0).

2. Become root and type snoop

   Use Ctl C to halt the process.

   # snoop Using device /dev/le (promiscuous mode) maupiti -> atlantic-82 NFS C GETATTR FH=0343 atlantic-82 -> maupiti NFS R GETATTR OK maupiti -> atlantic-82 NFS C GETATTR FH=D360 atlantic-82 -> maupiti NFS R GETATTR OK maupiti -> atlantic-82 NFS C GETATTR FH=1A18 atlantic-82 -> maupiti NFS R GETATTR OK maupiti -> (broadcast) ARP C Who is 129.146.82.36, npmpk17a-82 ?

3. Interpret results

   In the example, client maupiti transmits to server atlantic-82 using NFS file handle 0343. atlantic-82 acknowledges with OK. The conversation continues until maupiti broadcasts an ARP request asking who is 129.146.82.36?

   This example demonstrates the format of snoop. The next step is to filter snoop to capture packets to a file.

   Interpret the capture file using details described in RFC 1761. To access, use your favorite web browser with the URL: http://ds.internic.net/rfc/rfc1761.txt

How to capture snoop results to a file

1. As root, type snoop -o filename. Example:

   # snoop -o /tmp/cap Using device /dev/le (promiscuous mode) 30 snoop: 30 packets captured

   This has captured 30 packets in a file /tmp/cap. The file can be anywhere there is enough disk space. The number of packets captured is displayed on the command line, enabling you to press Ctl-C to abort at any time.

   snoop creates a noticeable networking load on the host machine, which can skew the results. To see reality at work, run snoop from a third system, (see the next section).

2. Type snoop -i filename to inspect the file:

   # snoop -i /tmp/cap 1 0.00000 frmpk17b-082 -> 224.0.0.2 IP D=224.0.0.2 S=129.146.82.1 LEN=32, ID=0 2 0.56104 scout -> (broadcast) ARP C Who is 129.146.82.63, grail ? 3 0.16742 atlantic-82 -> (broadcast) ARP C Who is 129.146.82.76, honeybea ? 4 0.77247 scout -> (broadcast) ARP C Who is 129.146.82.63, grail ? 5 0.80532 frmpk17b-082 -> (broadcast) ARP C Who is 129.146.82.92, holmes ? 6 0.13462 scout -> (broadcast) ARP C Who is 129.146.82.63, grail ? 7 0.94003 scout -> (broadcast) ARP C Who is 129.146.82.63, grail ? 8 0.93992 scout -> (broadcast) ARP C Who is 129.146.82.63, grail ? 9 0.60887 towel -> (broadcast) ARP C Who is 129.146.82.35, udmpk17b-82 ? 10 0.86691 nimpk17a-82 -> 129.146.82.255 RIP R (1 destinations)

   Refer to specific protocol documentation for detailed analysis and recommended parameters for ARP, IP, RIP and so forth. Searching the web is a good place to look at RFCs.

How to check packets between server and client

1. Establish a snoop system off a hub connected to either the client or server.

   The third system (the snoop system) sees all the intervening traffic, so the snoop trace reflects reality on the wire.

2. As root, type snoop with options and save to a file.

3. Inspect and interpret results.

   Look at RFC 1761 for details of the snoop capture file. To access, use your favorite web browser with the URL: http://ds.internic.net/rfc/rfc1761.txt

Use snoop frequently and consistently to get a feel for normal system behavior. For assistance in analyzing packets, look for recent white papers and RFCs, and seek the advice of an expert in a particular area, such as NFS or YP. For complete details on using snoop and its options, refer to the snoop(1M) man page.