System Administration Guide, Volume 3

Responsibilities of the Network Administrator

As a network administrator, your tasks generally fall into the following 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 might be responsible for all the phases, or you might 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 5, Planning Your TCP/IP 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 6, TCP/IP Administration 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

• Administering network security

• Administering network services, such as NFSTM services, name services, and electronic mail

• Troubleshooting network problems

“Configuring Network Clients” explains how to set up new hosts on an existing
network. “General Troubleshooting Tips” contains hints for solving network problems.
For information on network services, refer to Chapter 29, Solaris NFS Environment, Chapter 33, Introduction to Mail Services,
the Solaris Naming Administration
Guide, and the NIS+ Transition Guide. For security-related tasks, refer to the System Administration Guide, Volume
1.

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

“Configuring Routers” contains procedures for setting up an internetwork. “Extending Your Network With PPP” explains how to set up networking connections for nomadic computers. Chapter 25, Overview of UUCP 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 networking function, designers developed the concept
of the communications protocol.

The Solaris operating environment 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 environment.

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 4, Overview of TCP/IP.

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 2-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 2-1 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 can
be attached to the CPU board, or you might 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 can 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 can 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.

Note –

Installing network hardware is outside the scope of this guide. Refer to System Administration Guide, Volume
1 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 2-2 shows the basic elements involved in network communication.

Figure 2-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, Volume 1
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 “Naming Entities on Your 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 might 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 IPv4 Addressing Scheme”.

Hardware Address

Each host on a network has a unique 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 might need to access
information available from other companies, institutes of higher learning, and other
organizations not on your LAN. To obtain this information, they might 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 might 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, Volume 1. 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 [email protected], 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 that 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 can be inspected or modified using ndd(1M). 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 meanings are shown below.

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 is
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 that 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 uses 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>'

where <command> is either:

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

whereis either:

or

<ipaddr> delete

For example, the table above was created by:

# ndd -set /dev/tcp tcp_host_param '129.154.0.0 mask 255.255.255.0
        sendspace 8192 recvspace 8192'
# ndd -set /dev/tcp tcp_host_param '129.154.152.0 sendspace 32000
        recvspace 32000'
# ndd -set /dev/tcp tcp_host_param '129.154.152.6 sendspace 128000
        recvspace 128000 timestamp 1'

Note –

The example commands above have been broken over two lines. Each command should
be entered on one line.

It could be removed using these commands:

 
# ndd -set /dev/tcp tcp_host_param '129.154.152.6 delete'
# ndd -set /dev/tcp tcp_host_param '129.154.152.0 delete'
# 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 are only 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 is sent to the selected host or hosts when a connection is initiated.
However, if the value is 0, the timestamp option might still be sent, depending on
the settings of the tcp_tstamp_always and tcp_tstamp_if_wscale options.

TCP Selective Acknowledgment Support

The TCP selective acknowledgment (TCP SACK) provides
the support described in RFC 2018 to solve the problems related to congestion and
multiple packet drops especially in applications making use of TCP large windows (RFC
1323) over satellite links or transcontinental links. See RFC 2018 for complete details
on TCP SACK.

The configuration parameter is associated with the TCP device, /dev/tcp, and can be inspected or modified using ndd(1M). Normally, this parameter 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).

The available parameter and its meaning is shown below.

tcp_sack_permitted

Specifies whether SACK is permitted.
The default is 1. The available options are as follows:

0

TCP does not accept or send SACK information.

1

TCP does not initiate a connection with SACK_PERMITTED option. If the incoming request has SACK_PERMITTED option, TCP responds with SACK_PERMITTED option.

2

TCP initiates and accepts connections
with SACK_PERMITTED option.

For additional information see the tcp(7P) man page.