This chapter provides TCP/IP network reference information about network 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.This chapter contains the following information:TCP/IP Configuration Files Network Databases and the nsswitch.conf File Routing Protocols in the Solaris OS Network Classes Each system on the network obtains 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 the nsswitch.conf File describes in detail the concept of network databases. .This file defines the physical network interfaces on the local host. At least one /etc/hostname.interface file should exist on the local system. The Solaris installation program creates an /etc/hostname.interface file for the first interface that is found during the installation process. This interface usually has the lowest device number, for example eri0, and is referred to as the primary network interface. If the installation programs finds additional interfaces, you optionally can configure them, as well, as part of the installation process.If you add a new network interface to your system after installation, you must create an /etc/hostname.interface file for that interface, as explained in How to Configure a Physical Interface After System Installation. Also, 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 basic /etc/hostname.interface file contains one entry: the host name or IPv4 address that is associated with the network interface. The IPv4 address can be expressed in traditional dotted decimal format or in CIDR notation. If you use a host name as the entry for the /etc/hostname.interface file, that host name must also exist in the /etc/inet/hosts file. For example, suppose smc0 is the primary network interface for a system that is called tenere. The /etc/hostname.smc0 file could have as its entry an IPv4 address in dotted decimal notation or in CIDR notation, or the host name tenere .IPv6 uses the /etc/hostname6.interface file for defining network interfaces. For more information, refer to IPv6 Interface Configuration File. This file should contain one entry: the host name of the local system. For example, on system timbuktu, the file /etc/nodename would contain the entry timbuktu. 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. For more information on network domains, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). This file can 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. The presence of the /etc/defaultrouter file indicates that the system is configured to support static routing. The hosts database contains the IPv4 addresses and host names of systems on your network. If you use the NIS or DNS name service, or the LDAP directory 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 hostsbyname file. 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 system, and any other network addresses that the system must check for. For compatibility with BSD-based operating systems, the /etc/hosts file is a symbolic link to /etc/inet/hosts. The /etc/inet/hosts file uses the basic syntax that follows. Refer to the hosts4 man page for complete syntax information. IPv4-address hostname [nicknames] [#comment]IPv4-addressContains the IPv4 address for each interface that the local host must recognize. hostnameContains the host name that is assigned to the system 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. When you run the Solaris installation program on a system, 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 system tenere shown in Figure 5–1:127.0.0.1 localhost loghost #loopback address 192.168.200.3 tenere #host name In Example 10–1, the IPv4 address 127.0.0.1 is the loopback address. The loopback address is the reserved network interface that is used by the local system to allow interprocess communication. This address enables the host to send packets to itself. The ifconfig command uses the loopback address for configuration and testing, as explained in Monitoring the Interface Configuration With the ifconfig Command. Every system on a TCP/IP network must use the IP address 127.0.0.1 for IPv4 loopback on the local host. The IPv4 address 192.168.200.1 and the name tenere are the address and host name of the local system. They are assigned to the system's primary network interface. Some systems have more than one network interface, because they are either routers or multihomed hosts. Each network interface that is attached to the system requires its own IP address and associated name. During installation, you must configure the primary network interface. If a particular system has multiple interfaces at installation time, the Solaris installation program also prompts you about these additional interfaces. You can optionally configure one or more additional interfaces at this time, or manually, at a later date.After Solaris installation, you can configure additional interfaces for a router or multihomed host by adding interface information to the systems' /etc/inet/hosts file. For more information on configuring routers and multihomed hosts refer to Configuring an IPv4 Router and Configuring Multihomed Hosts.Example 10–2 shows the /etc/inet/hosts file for system timbuktu that is shown in Figure 5–1.127.0.0.1 localhost loghost 192.168.200.70 timbuktu #This is the local host name 192.168.201.10 timbuktu-201 #Interface to network 192.9.201 With these two interfaces, timbuktu connects networks 192.168.200 and 192.168.201 as a router. The NIS and DNS name services, and LDAP directory 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) for more information about these services.On a network that uses local files for the name service, systems that run in local files mode consult their individual /etc/inet/hosts files for IPv4 addresses and host names of other systems on the network. Therefore, these system's /etc/inet/hosts files must contain the following: Loopback address IPv4 address and host name of the local system (primary network interface) IPv4 address and host name of additional network interfaces that are attached to this system, if applicable IPv4 addresses and host names of all hosts on the local network IPv4 addresses and host names of any routers that this system must know about, if applicable IPv4 address of any system your system wants to refer to by its host name Figure 10–1 shows the /etc/inet/hosts file for system tenere. This system runs in local files mode. Notice that the file contains the IPv4 addresses and host names for every system 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 system that is configured as a network client uses the local /etc/inet/hosts file for its loopback address and IPv4 address.

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

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. 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 example, you could allocate one Class B network to Engineering, one Class B 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. 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 bits 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 Designing an IPv4 Addressing Scheme, 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 172.16.10, 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 byte 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 255.255.255.0 is applied to the IPv4 address 172.16.41.101, the result is the IPv4 address of 172.16.41.0.172.16.41.101 & 255.255.255.0 = 172.16.41.0In binary form, the operation is as follows:10000001.10010000.00101001.01100101 (IPv4 address)ANDed with11111111.11111111.11111111.00000000 (netmask)Now the system looks for a network number of 172.16.41 instead of a network number of 172.16. If your network has the number 172.16.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:255.255.192.0This netmask provides the following result:11111111.11111111.1100000.00000000This result still leaves 14 bits available for host addresses. Because all 0s and 1s are reserved, at least 2 bits must be reserved for the host number. If your network runs NIS or LDAP, the servers for these name services maintain netmasks databases. For networks that use local files for the name service, this information is maintained in the /etc/inet/netmasks file. For compatibility with BSD-based operating systems, the /etc/netmasks file is a symbolic link to /etc/inet/netmasks. The following example shows the /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: # # 128.32.0.0 255.255.255.0 192.168.0.0 255.255.255.0 If the /etc/netmasks file does not exist, create it with a text editor. Use the following syntax:network-number netmask-numberRefer to the netmasks4 man page for complete details.When creating netmask numbers, type the network number that is assigned by the ISP or Internet Registry (not the subnet number) and the netmask number in /etc/inet/netmasks. Each subnet mask should be on a separate line.For example: 128.78.0.0 255.255.248.0You 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. The inetd daemon starts up Internet standard services when a system boots, and can restart a service while a system is running. Use the Service Management Facility (SMF) to modify the standard Internet services or to have additional services started by the inetd daemon. Use the following SMF commands to manage services started by inetd:svcadmFor administrative actions on a service, such as enabling, disabling, or restarting. For details, refer to the svcadm1M man page. svcsFor querying the status of a service. For details, refer to the svcs1 man page. inetadmFor displaying and modifying the properties of a service. For details, refer to the inetadm1M man page. The proto field value in the inetadm profile for a particular service indicates the transport layer protocol on which the service runs. If the service is IPv4-only, the proto field must be specified as tcp, udp, or sctp.For instructions on using the SMF commands, refer to SMF Command-Line Administrative Utilities in System Administration Guide: Basic Administration. For a task that uses the SMF commands to add a service that runs over SCTP, refer to How to Add Services That Use the SCTP Protocol. For information on adding services that handle both IPv4 requests and IPv6 requests, refer to inetd Internet Services Daemon The network databases are files that provide information that is needed to configure the network. The network databases follow: hosts ipnodes netmasks ethers database 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 systems 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 system: local files, NIS, DNS, or LDAP. The format of your network database depends on the type of name service you select for your network. For example, the hosts database contains, at least the host name and IPv4 address of the local system and any network interfaces that are directly connected to the local system. 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: Networks that use local files for their name service rely on files in the /etc/inet and /etc directories. NIS uses databases that are called NIS maps. DNS uses records with host information. DNS boot and data files do not correspond directly to the network databases. The following figure shows the forms of the hosts database that are used by these name services.

This figure shows the various how the DNS, NIS, NIS+ name services and local files store the hosts database.

The following table lists the network databases and their corresponding local files and NIS maps.The ipnodes database is removed from Solaris releases after Solaris 10 11/06. Network Database Local Files NIS Maps hosts /etc/inet/hosts hosts.byaddr hosts.byname ipnodes /etc/inet/ipnodes ipnodes.byaddr ipnodes.byname netmasks /etc/inet/netmasks netmasks.byaddr ethers /etc/ethers ethers.byname ethers.byaddr bootparams /etc/bootparams bootparams protocols /etc/inet/protocols protocols.byname protocols.bynumber services /etc/inet/services services.byname networks /etc/inet/networks networks.byaddr networks.byname This book discusses network databases as they are viewed by networks that use local files for name services.Information about the hosts database is in hosts Database. Information about the netmasks database is in netmasks Database. Refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for information on network databases correspondences in NIS, DNS, and LDAP. 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 system, 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. # /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.conf4 man page describes the file in detail. The basic syntax is shown here: database name-service-to-searchThe 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 10–4, the only search option that is indicated is files. Therefore, the local system obtains security and automounting information, in addition to network database information, from files that are located in its /etc and /etc/inet directories.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: nsswitch.files nsswitch.nis nsswitch.nis+ If you want to change from one name service to another name service, 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 then nis. The following example shows the correct search paths.# /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). The bootparams database contains information that is used by systems that are configured to boot in network client mode. You need to edit this database if your network has network clients. See Configuring Network Clients for the procedures. The database is built from information that is entered into the /etc/bootparams file. The bootparams4 man page contains the complete syntax for this database. Basic syntax is shown here:system-name file-key-server-name:pathnameFor each network client system, 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 system. All items but the first item are optional. An example follows.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.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. The ethers database is built from information that is entered into the /etc/ethers file. This database associates host names to their Media Access Control (MAC) 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 MAC 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 ethers4 man page contains the complete syntax for this database. The basic syntax is shown here:MAC-address hostname #commentMAC-addressMAC address of the host hostnameOfficial name of the host #commentAny note that you want to append to an entry in the file The equipment manufacturer provides the MAC address. If a system does not display the MAC address during the system booting process, 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 , not to the nicknames, as follows.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 The remaining network databases seldom need to be edited.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 networks4 man page contains the complete syntax for /etc/inet/networks. The basic format is shown here:network-name network-number nickname(s) #commentnetwork-nameOfficial name for the network network-numberNumber assigned by the ISP or Internet Registry nicknameAny other name by which the network is known #commentAny 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.#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 # # local networks eng 192.168.9 #engineering acc 192.168.5 #accounting prog 192.168.2 #programming The protocols database lists the TCP/IP protocols that are installed on your system and their protocol numbers. The Solaris installation program automatically creates the database. This file seldom requires any administration. The protocols4 man page describes the syntax of this database. An example of the /etc/inet/protocols file follows.# # 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 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 services4 man page contains complete syntax information. An excerpt from a typical /etc/inet/services file follows.# # Network services # echo 7/udp echo 7/tcp echo 7/sctp6 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 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. RIP is implemented by in.routed, the routing daemon, which automatically starts when the system 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”). in.routed builds a full routing table exactly as it does on a router. Specify the S flag. in.routed creates a minimal kernel table, containing a single default route for each available router. 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.routed, which should run on both routers and hosts. On hosts, in.routed uses RDISC to discover default routes from routers that advertise themselves through RDISC. On routers, in.routed uses RDISC to advertise default routes to hosts on directly-connected networks. See the in.routed1M man page and the gateways4 man page. Class-based network numbers are no longer available from the IANA, though many older networks are still class-based. This section provides details about IPv4 network classes. 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.A class A network number uses the first 8 bits of the IPv4 address as its “network part.” The remaining 24 bits contain the host part of the IPv4 address, as the following figure illustrates.

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 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. Only the first byte of a class A number is registered with the IANA. Use of the remaining three bytes is left to the discretion of the owner of the network number. Only 127 class A networks exist. Each one of these numbers can accommodate a maximum of 16,777,214 hosts. 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 172.16.50.56, the first two bytes, 172.16, are registered with the IANA, and compose the network address. The last two bytes, 50.56, contain 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.

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

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 192.168.2.5. The first three bytes, 192.168.2, form the network number. The final byte in this example, 5, is the host number.