System Administration Guide: IP Services

Chapter 5 TCP/IP (Reference)

This chapter provides TCP/IP network reference information about TCP/IP configuration files, including the types, their purpose, and the format of the file entries. The existing network databases are also described in detail.

The chapter also shows how the structure of IPv4 addresses are derived, based on defined network classifications and subnet numbers.

For additional information about Internet Transmission Control Protocol (TCP), see the tcp(7P) man page.

This chapter contains the following information:

TCP/IP Configuration Files

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

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. For information on the ipnodes file, see /etc/inet/ipnodes File.

/etc/hostname.interface File

This file defines the network interfaces on the local host for IPv4. A minimum of 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.

Note –

If you add a new network interface to your system after the initial Solaris software installation, you must create an /etc/hostname.interface file for that interface, add the interface's IP address to the /etc/inet/hosts file, and reboot the system with the -r option. See substeps within How to Configure a Host for Local Files Mode for instructions. Also, in order for the Solaris software to recognize and use the new network interface, you need to load the interface's device driver into the appropriate directory. Refer to the documentation that comes with the new network interface for the appropriate interface name and device driver instructions.

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

Files 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, which is shown in Figure 4–1. This machine has two network interfaces and functions as a router. The primary network interface le0 is connected to network 192.9.200. The IP address is, 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. This interface is connected to network 192.9.201. Although this interface is physically installed on machine timbuktu, the interface must have a separate IPv4 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/hostname6.interface File

IPv6 uses the file /etc/hostname6.interface at start up to automatically define network interfaces in the same way IPv4 uses /etc/hostname.interface. A minimum of one /etc/hostname. or /etc/hostname6. file should exist on the local machine. The Solaris installation program creates these files for you. In the file name, replace interface with the device name of the primary network interface. For more information about the /etc/hostname6.interface file, see IPv6 Network Interface Configuration File.

/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 For more information on network domains, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

/etc/defaultrouter File

This file should contain an entry for each router that is 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 IPv4 addresses and host names of machines on your network. If you use the NIS, NIS+, or DNS name services (or LDAP as a name service), the hosts database is maintained in a database that is designated for host information. For example, on a network that runs NIS+, the hosts database is maintained in the host table.

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

Note –

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 the basic syntax that follows. Refer to the hosts(4) man page for complete syntax information.

IPv4-address hostname [nicknames] [#comment]

IPv4-address contains the IPv4 address for each interface that the local host must recognize.

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

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

[# comment] is an optional field for a comment.

Initial /etc/inet/hosts File

When you run the Solaris installation program on a machine, the program configures the initial /etc/inet/hosts file. This file contains the minimum entries that the local host requires. The entries include the loopback address, the host IPv4 address, and the host name.

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

Example 5–1 /etc/inet/hosts File for Machine ahaggar     localhost         loghost    #loopback address   tenere                      #host name

Loopback Address

In Example 5–1, the IPv4 address is the loopback address. The loopback address is the reserved network interface that is used by the local machine to allow interprocess communication. This enables the host to send 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 for the local host.

Host Name

The IPv4 address and the name tenere 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, because they are either routers or multihomed hosts. Each additional network interface that is attached to the machine requires its own IPv4 address and associated name. When you configure a router or multihomed host, you must add this information manually to the router's /etc/inet/hosts file. See Configuring Routers for more information on configuring routers and multihomed hosts.

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

Example 5–2 /etc/inet/hosts File for Machine timbuktu      localhost     loghost   timbuktu      #This is the local host name   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 (or LDAP as a name service) maintain host names and addresses on one or more servers. These servers maintain hosts databases that contain information for every host and router (if applicable) on the servers' network. Refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) and System Administration Guide: Naming and Directory Services (FNS and NIS+) for more information about these services.

When Local Files Provide Name Service

On a network that uses local files for name service, machines that run in local files mode consult their individual /etc/inet/hosts files for IPv4 addresses and host names of other machines on the network. Therefore, these machine's /etc/inet/hosts files must contain the following:

The figure below shows the /etc/inet/hosts file for machine tenere. This machine runs in local files mode. Notice that the file contains the IPv4 addresses and host names for every machine on the 192.9.200 network. The file also contains the IPv4 address and interface name timbuktu-201. This interface connects the 192.9.200 network to the 192.9.201 network.

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

Figure 5–1 /etc/inet/hosts File for Machine Running in Local Files Mode

Shows what the hosts file might look like for a machine that is running in local files mode.

ipnodes Database

The ipnodes database contains the IPv6 addresses and host names of machines on your network. If you use the NIS, NIS+, or DNS name services (or LDAP as a name service), the ipnodes database is maintained in a database that is designated for host information. For example, on a network that runs NIS+, the ipnodes database is maintained in the host table. For more information about the ipnodes database, see /etc/inet/ipnodes File.

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.

Note –

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 maximizing the limited 32-bit IPv4 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 that is allocated to new network addresses is known as the subnet number.

In addition to making more efficient use of the IPv4 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, the administration of 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 division can also reduce the amount of routing information that must be communicated among routers.

Creating the Network Mask for IPv4 Addresses

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 bits and which represent the host number. Recall that the complete IPv4 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. 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 Administering Network Numbers, 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 to either the network number or the host number, depending on the network class.

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

If you are to implement subnetting, you need to use some of the bits in the bytes that are 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 network.

The bits in the host address bytes that are applied to subnet addresses and those applied to host addresses are 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 IPv4 address by using the bitwise logical AND operator. This operation selects out the network number and subnet number positions of the address.

Netmasks can be explained 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 is applied to the IPv4 address, the result is the IPv4 address of & =

In binary form, the operation is as follows:

10000001.10010000.00101001.01100101 (IPv4 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 your network has the number 129.144.41, that number is what the system checks for and finds. Because you can assign up to 254 values to the third byte of the IPv4 address space, subnetting lets you create address space for 254 networks, where previously space was available for only one.

If you are providing address space for only two additional networks, you can use the following subnet mask:

This netmask provides the following result:


This result still leaves 14 bits available for host addresses. Because all 0s and 1s are reserved, a minimum of 2 bits must be reserved for the host number.

/etc/inet/netmasks File

If your network runs NIS, NIS+, or LDAP, 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.

Note –

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

The following example shows the /etc/inet/netmasks file for a class B network.

Example 5–3 /etc/inet/netmasks File for a Class B Network

 ## The netmasks file associates Internet Protocol (IPv4) address
 # masks with IPv4 network numbers.
 # 	network-number	netmask
 # Both the network-number and the netmasks are specified in
 # “decimal dot” notation, e.g:

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 that is 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:

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.

Network Databases and nsswitch.conf File

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

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 nsswitch.conf file is not a network database, you need to configure this file along with the relevant network databases. nsswitch.conf specifies which name service to use for a particular machine: local files, NIS, NIS+, DNS, or LDAP.

How Name Services Affect Network Databases

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

The network databases are used as follows:

Note –

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

The following figure shows the forms of the hosts database that is used by these name services.

Figure 5–2 Forms of the hosts Database Used by Name Services

Diagram shows networks running, DNS, NIS, and NIS+, and the associated network databases.

The following table lists the network databases and how they are used by local files, NIS+, and NIS.

Table 5–1 Network Databases and Corresponding Name Service Files

Network Database 

Local Files 

NIS+ Tables 

NIS Maps 




hosts.byaddr hosts.byname




ipnodes.byaddr ipnodes.byname








ethers.byname ethers.byaddr








protocols.byname protocols.bynumber








networks.byaddr networks.byname

This book discusses network databases as viewed by networks that use local files for name services. Information about the hosts database is in hosts Database. Information about the ipnodes database is in /etc/inet/ipnodes File. Information about the netmasks database is in netmasks Database. Refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) and System Administration Guide: Naming and Directory Services (FNS and NIS+) for information on network databases correspondences in NIS, NIS+, DNS, and LDAP.

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 the following example.

Example 5–4 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 "" 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. The file's basic syntax is:

database name-service-to-search

The database field can list one of many types of databases that are searched by the operating system. For example, the field could indicate a database that affects 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 5–4, the only search option that is indicated is files. Therefore, the local machine obtains security and automounting information, in addition to network database information, from files that are located in its /etc and /etc/inet directories.

Changing nsswitch.conf

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

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 that runs NIS, you might have to change the nsswitch.conf file on network clients. The search path for the bootparams and ethers databases must list files as the first option, and nis. The following example shows the correct search paths.

Example 5–5 nsswitch.conf for a 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 System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) and System Administration Guide: Naming and Directory Services (FNS and NIS+).

bootparams Database

The bootparams database contains information that is used by machines that are configured to boot in the network client mode. You need to edit this database if your network has network clients. See Configuring Network Clients for procedures. The database is built from information that is entered into the /etc/bootparams file.

The bootparams(4) man page contains complete syntax for this database. The man page's basic syntax is shown in the following example:

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

For each 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. An example follows.

Example 5–6 bootparams Database

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

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

Wildcard Entry for bootparams

In most instances, use the wildcard entry when editing the bootparams database to support clients. This entry follows:

*  root=server:/path dump=:

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

ethers Database

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

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 this file on all hosts that are running the daemon to reflect changes to the network.

The ethers(4) man page contains complete syntax information for this database. The man page's basic format follows:

Ethernet-address hostname #comment

Ethernet-address is the Ethernet address of the host.

hostname is the official name of the host.

#comment is any note that 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, ensure that host names correspond to the primary names in the hosts and ipnodes databases, not to the nicknames, as follows.

Example 5–7 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. This file contains the names of all networks to which your network connects through routers.

The Solaris installation program configures the initial networks database. However, if you add a new network to your existing network topology, you must update this database.

The networks(4) man page contains full syntax information for /etc/inet/networks. The man page's basic format follows:

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 note that you want to append to an entry in the file.

You must maintain the networks file. The netstat program uses the information in this database to produce status tables.

A sample /etc/networks file follows.

Example 5–8 /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 that are installed on your system and their numbers. The Solaris installation program automatically creates the database. This file seldom requires any administration.

The protocols database contains the names of the TCP/IP protocols that are installed on the system. The protocols(4) man page describes the syntax of this database. An example of the /etc/inet/protocols file follows.

Example 5–9 /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. This database is used by programs that call network services. The Solaris installation automatically creates the services database. Generally, this database does not require any administration.

The services(4) man page contains complete syntax information. An excerpt from a typical /etc/inet/services file follows.

Example 5–10 /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

Booting Processes

Note –

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/ startup script.

  4. The script runs a number of system startup tasks, including the establishment of the minimum host and network configurations for diskless and dataless operations. /etc/rcS.d/ 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/ 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 requirement is necessary because no internetwork communications exist at this point.

  6. After /etc/rcS/ 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: Basic Administration for a complete description of the booting process.

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:

ICMP Router Discovery (RDISC) Protocol

Hosts use 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.

RDISC is implemented by in.rdisc, which should run on both routers and hosts. Normally, when in.rdisc runs on a host, in.rdisc enters a default route for each router that is also running in.rdisc. A host that is running in.rdisc cannot 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.

How a Machine Determines if 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:

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 considered.

Parts of the IPv4 Address

Each network that runs TCP/IP must have a unique network number. Every machine on the network must have a unique IP address. You must understand how IP addresses are constructed before you register your network and obtain its network number. This section describes IPv4 addresses. For information on IPv6 addresses, see IPv6 Addressing.

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

The bytes of the IPv4 address are further classified into two parts: the network part and the host part. The following figure shows the component parts of a typical IPv4 address,

Figure 5–3 Parts of an IPv4 Address

Diagram shows that 129.144 is the network part and 50.56 is the host part of an IPv4 address.

Network Part

The network part specifies the unique number that is assigned to your network. The network part also identifies the class of network that is assigned. In Figure 5–3, the network part occupies two bytes of the IPv4 address.

Host Part

This is the part of the IPv4 address that you assign to each host. The host part uniquely identifies this machine on your network. Note that for each host on your network, the network part of the address is 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 IPv4 address space by using some of the bits from the host number part of the IPv4 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 bitmask that selects the network and subnet parts of an IPv4 address. Refer to Creating the Network Mask for IPv4 Addresses for details.

Network Classes

The first step in planning for IPv4 addressing on your network is to determine which network class is appropriate for your network. After you have completed this step, you can move to 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 IPv4 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 8 bits of the IPv4 address as its “network part.” The remaining 24 bits compose the host part of the IPv4 address, as the following figure illustrates.

Figure 5–4 Byte Assignment in a Class A Address

Diagram shows bits 0-7 is network part and remaining 24 bits are host part of a 32 bit IPv4 Class A address.

The values that are assigned to the first byte of class A network numbers fall within the range 0–127. Consider the IPv4 address 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 a maximum of 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, the first two bytes, 129.144, are assigned by the InterNIC, and compose the network address. The last two bytes, 50.56, compose the host address, and are assigned at the discretion of the owner of the network number. The following figure graphically illustrates a class B address.

Figure 5–5 Byte Assignment in a Class B Address

Diagram shows bits 0-15 is network part and remaining 16 bits are host part of a 32 bit IPv4 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 IPv4 address. Only the fourth byte is assigned at the discretion of the network owners. The following figure graphically represents the bytes in a class C address.

Figure 5–6 Byte Assignment in a Class C Address

Diagram shows bits 0-23 is network part and remaining 8 bits are host part of a 32 bit IPv4 Class C address.

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