This appendix addresses some of the configuration issues that arise when a
server is equipped with multiple network interfaces, and the network is
divided into multiple segments.
Issues covered in this appendix include configuration of network addresses,
NFS, NIS, and diskless clients. More general information on these topics can be
found in the System and Network Administration manual.
Note that most of the information contained in this appendix is valid with or
without Sun Network CoProcessors. It is pertinent to multiple network
configurations in general.
In the remainder of this appendix, we will use the following terms:
Segment
Used when referring to a physical network, i.e., an Ethernet cable.
Host
Used to indicate generically a workstation or a server.
Machine
Used interchangeably with the term "host".
Hostname
The hostname (spelled in one word) of a machine will refer to the output of the
/usr/bin/hostname command issued on that machine.
Host Name
Host Name (spelled in two words) refers to any host name as it appears in an
entry of an /etc/hosts file. A gateway machine configured with multiple
network interfaces has only one "hostname" at a given point in time. However,
it has multiple host names, each associated with an IP address configured on a
network interface on that machine.
Network
When it is not further qualified (such as in "IP network", or "Class C
network"), this term will be used generically to refer to the totality of the
interconnected devices, regardless of how many segments (i.e., physical
Ethernet cables) they span.
Reconfiguring a network usually involves defining new network addresses,
moving workstations to new Ethernet segments, and redistributing client
machines on server machines.
In planning for a network reconfiguration, the following considerations should
be kept in mind:
-
Heavy data users should be kept close to the data they use. Crossing
intermediate machines to access data will only degrade network
performance.
-
Clustering users of the same set of data into work groups local to a segment
is desirable. It allows for maximum data sharing, and minimum
internetwork traffic.
-
Connectivity of services should be maintained. Some network services, such
as the Network Information Service (NIS), do not cross boundaries of
Ethernet segments. Gateway machines often have to act as NIS server on
one of the network segments they are connected to, while binding into the
domain of a master NIS server located on another segment they are
connected to. Gateway machines thus configured act as relays in the
propagation of NIS information across interconnected segments.
-
Drawing pictures of the network before and after reconfiguration is strongly
encouraged. This should be done before any of the configuration work is
started.
Reconfiguring a network is, by nature, a global task. Keeping a global,
pictorial view of the network can be of significant help in achieving quick
success.
F.2.1
Illustrative Example
To provide a framework for the current discussion, we will use an example of
reconfiguration as illustrated in Figure F-1 and Figure F-2.
We start out with a network comprised of a single Ethernet segment, and five
hosts of interest. Please refer to Figure F-1.
F.2.2
Hosts of Interest
Five hosts will be initially involved in our example reconfiguration. In
addition, a sixth host will be introduced into the network. These hosts are:
nismaster: this machine is the NIS master server on the network.
nfsserver: this machine is the NFS server for the clients of interest. It is a
SPARCserver 690MP, running SunOS 4.1.3.
dfc_a: this machine is a diskfull, dataless, workstation. We assume that it
mounts some file systems from the server nfsserver, via NFS. A sample
entry from its /etc/fstab file follows:
Figure F-1
Original Network Configuration
dlc_a: this machine is a diskless SPARCstation client of nfsserver. We
assume that it mounts all of its file systems from nfsserver in the following
fashion:
dlc_b: this machine is a diskless SPARCstation client of nfsserver. We
assume that it mounts all of its file systems from nfsserver in the following
fashion:
new_b: this machine is not part of the original network setup. It will be
introduced as part of the reconfiguration process.
Note that hosts dfc_a and dlc_a both use the /data_a file system data.
When introduced, machine new_b will be a user of the /data_b file system
data, similarly to machine dlc_b.
F.2.3
Initial Network Configuration
Initially, all hosts of interest are connected to a single Ethernet segment. In
particular, the SPARCserver 690MP machine nfsserver has a single network
interface configured, namely le0. We will refer to this original segment as
segment "O". In addition, nismaster is the NIS master, and it is the only NIS
server on the network. The other hosts on the network are NIS clients of
nismaster.
We assume that the initial network number is 192.9.200.0, with a standard
netmask of 255.255.255.0. This is a Class C network. The file /etc/netmasks
on the host nismaster has the following entry:
Below are the contents of the three files /etc/hosts, /etc/ethers, and
/etc/bootparams on the server nismaster:
In addition, the file /etc/rc.local on the host nismaster starts the
ypserv process.
On the host nfsserver, the /etc/exports file appears as follows:
The directory /tftpboot on nfsserver has the following symbolic link
entries (boot files for dlc_a and dlc_b):
(The first part of the name of each symbolic link represents the hexadecimal
translation of the corresponding IP address.)
The /etc/rc.local file on nfsserver starts the ypbind daemon, but it
does not start the ypserv daemon. This illustrates the fact that nismaster is
the only NIS server on the network.
The /etc/hosts file on host dlc_a has the following contents, so it can find
nfsserver and mount its / and /usr file systems before NIS is activated:
The /etc/hosts file on host dlc_b has the following contents, so it can find
nfsserver and mount its / and /usr file systems before NIS is activated:
Finally, both dlc_a and dlc_b start the ypbind daemon in their
/etc/rc.local scripts.
F.2.4
Intended New Configuration
It is intended to split the network into three Ethernet segments by upgrading
the SPARCserver 690MP nfsserver with two Sun Network CoProcessor
subsystems. We assume that this is done at the occasion of adding a new
diskless SPARCstation client new_b, which will be using data in /data_b on
nfsserver.
While the le0 interface on nfsserver remains connected to segment "O", the
two new interfaces, ne0 and ne1, will be connected to two new segments,
referred to as segment "A" and segment "B", respectively.
Since hosts dfc_a and dlc_a share the data in /data_a, they will be moved
to segment "A". Host dlc_b will be moved to segment "B", and host new_b
will be added on segment "B". Please refer to Figure F-2.
It is also decided to move from a Class C network to a Class B network, due to
the increase in the number of hosts attached to the network.
Figure F-2
New Network Configuration
This section outlines the steps involved in reconfiguring the network. Topics
covered include network numbering and related NIS updates, NIS
connectivity, NFS mounts, reconfiguration of diskless clients, and addition of
new diskless clients.
Every subsection in this section will be further divided into three parts:
The first part explains, in general terms, the steps to be accomplished.
The second part illustrates these steps on the chosen example.
The third part discusses variations on the scenario, such as different
configuration parameters, non-NIS cases, etc.
The first step in the reconfiguration consists of choosing new network numbers
and network masks. This choice is largely dependent on the number of
Ethernet segments and the number of hosts that exist on the network.
Caution -
If your network is connected to world-wide Internet, you must
obtain your new network numbers from the Internet Network Information
Center.
While the class of the network determines the maximum number of
interconnected hosts, the choice of the mask shapes how these hosts are
distributed on subnets.
In an NIS environment, the steps involved in renumbering the network are:
1. Updating the file /etc/netmasks on the NIS master, to include the new
network numbers and their associated subnet masks.
2. Updating the file /etc/hosts on the NIS master to reflect all the new
addresses and, possibly, host names if those were changed.
3. Updating the file /etc/hosts on all other machines to reflect their own
new address as well as the new address of their file server, if they are
diskless.
4. Updating the file /etc/hostname.??0 on all machines whose host name
is changing.
5. Creating more /etc/hostname.??? files on gateway machines.
Example
In the example, we assume that the reconfigured network will be numbered in
the following fashion:
Network Number = 128.32.0.0
Subnet Mask = 255.255.255.0
Subnet "O" = 128.32.1.0
Subnet "A" = 128.32.2.0
Subnet "B" = 128.32.3.0
nismaster IP address = 128.32.1.1 (nismaster host name is unchanged.)
nfsserver IP addresses = 128.32.1.2 on interface le0
128.32.2.2 on interface ne0
128.32.3.2 on interface ne1
Associated host names = nfsserver for 128.32.1.2
nfsserver_a for 128.32.2.2
nfsserver_b for 128.32.3.2
We also assume that the hostname of nfsserver, as displayed by the
/usr/bin/hostname command, remains as nfsserver.
dfc_a IP address = 128.32.2.3 (dfc_a host name is unchanged.)
dlc_a IP address = 128.32.2.4 (dlc_a host name is unchanged.)
dlc_b IP address = 128.32.3.5 (dlc_b host name is unchanged.)
new_b IP address = 128.32.3.6
Note that, although the value of the subnet mask has not changed, (it still is
255.255.255.0), its impact has changed because we changed from a Class C
network to a Class B network.
Indeed, in a Class C network, the first three octets of an Internet address define
the network field, whereas the fourth octet is to be split between the subnet
field and the host field. Since, in our example (255.255.255.0), the subnet mask
covers only the first three octets of the Internet address, and does not cross
over to the fourth octet, this remaining octet of the Internet address defines the
host field of the address.
In contrast, when we move to a Class B network, the first two octets of an
Internet address define the network field. The remaining two octets are split
between the subnet field and the host field of the address. Since, in our
example (255.255.255.0), the subnet mask covers the first three octets of the
Internet address, it follows that the third octet of the Internet address defines
the subnet field, while the fourth octet of the Internet defines the host field. We
have thus defined a single IP network comprised of three subnets.
We now apply the steps described earlier in this section to this example:
1. The file /etc/netmasks on the host nismaster is changed to have the
following entry:
2. The file /etc/hosts on the host nismaster is changed to have the
following entries:
3. Every host's /etc/hosts file is changed to reflect the new mapping of its
own host name to its new IP address. In addition, every diskless client's
/etc/hosts file is changed to reflect the updated mapping of its file
server's host name to the corresponding IP address. The file server's host
name and IP address mentioned here are those that are configured on the
file server's interface over which the diskless client is booted.
4. Thus, for example, the updated /etc/hosts file of nfsserver includes
the following entries:
5. Note that, for machines with multiple configured interfaces, such as
nfsserver, the machine has only one hostname, as displayed by the
/usr/bin/hostname command. We'll assume it is still "nfsserver" for
the machine nfsserver. This hostname is what appears on the login
prompt on that machine.
6. The updated /etc/hosts file of dlc_a includes the following entries:
7. The updated /etc/hosts file of dfc_a includes the following entry:
8. Note that, in this case, the entry nfsserver_a does not have to appear
explicitly because it can be learned via the NIS mechanism. By contrast, a
diskless client needs to know its file server's host name at a point in the
boot sequence when NIS is not enabled yet.
9. The machine nfsserver has two new interfaces configured. It is updated
to have the following three files:
/etc/hostname.le0 containing "nfsserver"
/etc/hostname.ne0 containing "nfsserver_a"
/etc/hostname.ne1 containing "nfsserver_b".
F.3.2
Variations
We will discuss two variations on the scenario depicted above.
1.
The first variation is the case where the network is split up from one Class C
network into three Class C networks, rather than one Class B network made
of three subnets.
-
In this case, the file /etc/netmasks on nismaster would have three
entries in it, of the form:
192.9.200.0 255.255.255.0 IP Network "O"
192.9.201.0 255.255.255.0 IP Network "A"
192.9.202.0 255.255.255.0 #IP Network "B"
-
Also, machines on the network would have IP addresses of the form:
"192.9.200.XXX" if they were on IP network "O",
"192.9.201.XXX" if they were on IP network "A",
"192.9.202.XXX" if they were on IP network "B".
2.
The second variation is the case where the NIS system is not running on the
network, or a host chooses to not participate in NIS. In that case, the host
not binding into NIS should have its own /etc/netmasks file, and its own
/etc/hosts file updated as described above for the machine nismaster.
Similarly, in the case where NIS is not running at all, these files should be
replicated on every host in the network.
F.4.1
Steps
When the network is split up into several segments, the issue of NIS
connectivity arises. This is because the NIS system does not naturally cross
segment boundaries. An NIS client that attempts to bind into an NIS domain
can only do so if there is an NIS server on the same Ethernet segment.
Care should therefore be taken to have at least one NIS server on every
segment. This NIS server should in addition have access to the NIS master
server, in order to obtain the databases.
F.4.2
Example
In our example, clients such as dfc_a, dlc_a, and dlc_b do not have direct
access to the NIS master server nismaster. In order to give them access to the
NIS databases resident on nismaster, the machine nfsserver should run
both the ypbind daemon, so as to get the information from nismaster, and
the ypserv daemon, so as to be able to service NIS requests from hosts on
segments "A" and "B".
F.4.3
Variations
Variations could include definition of several NIS domains, or suppression of
the NIS system on parts of the network. If this is not otherwise desired, the
reconfiguration of the network into several segments does not mandate doing
that.
F.5.1
Steps
After the network is reconfigured, NFS clients can end up communicating with
their NFS server over a different network interface on the server than what was
previously used. The new interface is likely to have a new host name
associated with its IP address. The typical case is for clients to use a generic
name for a server when mounting NFS file systems from the server. This
generic name is typically associated with the primary network interface of the
server. In the previous example, that name would be nfsserver. Using the
generic name makes the task of administering NFS mounts easier.
If you take the generic-server naming approach, it is very important to update
your /etc/rc.local file so that every SNC interface is advised to preprocess
NFS requests directed to the generic interface. In the example below, you
would edit /etc/rc.local on nfsserver as follows:
This then becomes
If you don't make the change shown above, you will not eliminate NFS service
to the client. What will happen is that the SNC will not preprocess NFS
requests for that server; in effect, removing the SNC from the network for that
server. The NFS requests will instead be processed by the generic NFS server
on the host CPU.
F.5.2
Variations
Mounting file systems across gateways is possible and supported. For instance,
it would be possible for dlc_b to mount file systems off dfc_a or nismaster,
by crossing two interfaces on the gateway nfsserver. This is particularly not
recommended when the gateway is also a heavily used NFS server, as NFS
performance will suffer from the internetwork traffic.
F.6.1
Steps
Two steps involving the client's /etc/hosts and /etc/fstab files have
already been covered in Section F.3.1 and Section F.5, respectively.
In addition, the following steps have to be followed:
-
The file /etc/ethers on the NIS master has to be updated if the client host
name was modified. The new client host name should now be mapped to
the client's Ethernet address.
-
The file /etc/bootparams on the NIS master should be updated to reflect
the new host name on the NFS server's network interface over which the
diskless client is booted.
-
The file /etc/exports on the NFS server should be updated to reflect the
new diskless client's host name, if the latter was modified after the network
reconfiguration.
-
The entries in the directory /tftpboot on the NFS server should be
updated to match the new IP addresses of the diskless clients.
F.6.2
Example
In this example, diskless clients kept their original host names, even though
their IP addresses were modified. There is no need for updating the file
/etc/ethers on nismaster. This step would have been necessary, though, if
any of the diskless clients had changed its host name.
1. The file /etc/bootparams on nismaster is updated as follows:
2. Since none of the diskless clients changed its host name in this example,
there is no need for changing the file /etc/exports on nfsserver. If
any diskless client had changed its host name, then the file
/etc/exports on the server would have been updated such that entries
of the form would have needed new values for the client named client.
/export/root/client -access=client,root=client
/export/swap/client access=client,root=client
3. The directory /tftpboot on nfsserver is updated with the following
symbolic link entries (boot files for dlc_a and dlc_b) thus reflecting the
new IP addresses of dlc_a and dlc_b.:
80200204.SUN4C -'> boot.sun4c.sunos.4.1.1
80200305.SUN4C -'> boot.sun4c.sunos.4.1.1
Note that "80200204" is the hexadecimal transcription for the IP address
"128.32.2.4", and "80200305" is the hexadecimal transcription for the IP
address "128.32.3.5".
F.6.3
Variations
In the case where the NIS system was disabled on the network, or the host
nfsserver did not participate in NIS, the file /etc/bootparams (and
possibly the files /etc/ethers and /etc/exports) would have been
updated locally on the NFS server nfsserver.
F.7.1
Steps
When the program /usr/etc/install/add_client is used on the NFS
server to create a new diskless client, it does not take into account the multiple
network configuration, in several respects. These shortcomings all come from
the fact that add_client does not recognize the fact that the NFS server is
configured with multiple network interfaces.
Instead, the hostname of the NFS server, as output by the command
/usr/bin/hostname is always used in the files created by add_client.
This only works correctly if the new diskless client is attached to the segment
on which the NFS server's IP address matches the hostname returned by
/usr/bin/hostname. It does not work for diskless clients added on other
segments attached to the NFS server.
Note that this fact is true regardless of the nature of the extra network
interfaces (le or ne).
-
The file /etc/bootparams on the NIS master may be updated with the
wrong host name for the NFS server. These fields have to be manually
updated to use the actual host name belonging to the NFS server's network
interface over which the diskless client will boot.
-
The file /etc/hosts on the client may be created with the wrong entry for
its NFS server's host name and IP address. These fields should be corrected
to use the NFS server's host name on the network interface over which the
diskless client will boot.
-
The file /etc/fstab on the client may be created with the wrong host
name for the NFS server. These fields should be corrected manually to use
the NFS server's host name on the network interface over which the diskless
client will boot.
Note -
A useful alternative to the steps above is to change the hostname on the
NFS server by means of the /usr/bin/hostname command, prior to running
the /usr/etc/install/add_client program. The NFS server can be configured, if
only on a temporary basis, with the hostname that will produce the correct
entries in the files /etc/bootparams, /etc/hosts, and /etc/fstab. The NFS
server's hostname can then be reverted back to its original value by running
the command /usr/bin/hostname again, after add_client is completed.
This procedure is particularly timesaving when adding a large number of
diskless clients on a segment.
F.7.2
Example
In our example, we have chosen to add a new diskless client called new_b.
After the program /usr/etc/install/add_client has successfully
completed on nfsserver, the following remains to be done manually:
1. The file /etc/bootparams on nismaster will have an entry of the form:
2. This entry should be changed to:
3. The file /etc/hosts on new_b will have the entry:
4. The following entry is more pertinent:
5. Note that the old entry can remain, because it is not incorrect. If NIS is
running, though, it will not be used.
6. The file /etc/fstab on new_b will have the entries:
7. These should be changed to:
8. As an alternative to the three steps above, the hostname of nfsserver
can be changed to nfsserver_b prior to running add_client. This is
done by issuing the command:
9. If the add_client program is then run, it will produce entries in
/etc/bootparams, /etc/fstab, and /etc/hosts with nfsserver_b,
rather than nfsserver.
10. The hostname can then be changed back to nfsserver by issuing the
command:
F.7.3
Variations
In the case where NIS is not enabled on the network, or if the NFS server
nfsserver does not participate in NIS, the file /etc/bootparams will have
to be corrected locally on the NFS server, rather than on the NIS master.