To add a new host to thenetwork, you must:
5.2.1 Configuring the Network Interface with ifconfigThe ifconfig command ("if" for interface) is used to set the basic characteristics of the network adapter, the most important of which is associating an IP address with the interface. Here are some typical commands: # ifconfig lo0 localhost up # ifconfig eth0 inet 192.168.1.9 netmask 255.255.255.0 The first command configures the loopback interface, designating it as up (active). In many versions of ifconfig, up is the default when the first IP address is assigned to an interface, and thus it is usually omitted. The second command configures the Ethernet interface on this system, named en0, assigning it the specified Internet address and netmask. The second parameter in the second ifconfig command designates the address family. Here, inet refers to IPv4; inet6 is used to refer to IPv6. This parameter is optional and defaults to IPv4. The first example command above also illustrates the use of a hostname to specify the IP address. If you do so, the IP address corresponding to the hostname must be available when the ifconfig command is run, generally because it is in /etc/hosts. FreeBSD, Solaris, and Tru64 systems allow you to replace the IP address and netmask parameters with a CIDR address: # ifconfig tu0 192.168.9.6/24 5.2.1.1 Ethernet interface namesThe loopback interface is almost always named lo0 (but Linux calls it simply lo). Ethernet interface names vary tremendously among systems. Here are some common names for the first Ethernet interface on the various systems:[16]
5.2.1.2 Other uses of ifconfigWithout any other options, ifconfig displays the configuration of the specified network interface, as in this example: $ ifconfig eth0 en0: flags=c63<UP,BROADCAST,NOTRAILERS,RUNNING,FILTMULTI,MULTICAST> inet 192.168.1.9 netmask 0xffffff00 broadcast 192.168.1.255 You can display the status of all configured network interfaces with ifconfig -a except under HP-UX. On AIX, FreeBSD, and Tru64 systems, the -l option can be used to list all network interfaces: $ ifconfig -l en0 en1 lo0 This system has two Ethernet interfaces installed, as well as the loopback interface. The HP-UX lanscan command provides similar functionality. 5.2.1.3 ifconfig on Solaris systemsSolaris systems provide two versions of ifconfig, one in /sbin and another in /usr/sbin. Their syntax is identical. They differ only in the way in which they attempt to resolve hostnames specified as arguments. The /sbin version always checks /etc/hosts before consulting DNS, while the other version uses whatever name resolution order is specified in the network switch file (discussed below). The former is used at boot time, when DNS may not be available. Solaris also requires that an interface be "plumbed" before it is configured, via commands like the following: # ifconfig hme0 plumb # ifconfig hme0 inet 192.168.9.2 netmask + up The first command sets up the kernel data structures needed for the device to be used with IP. Other operating systems also perform this setup function, but they do so automatically when the first IP address is assigned to an interface. The plus sign parameter to the netmask keyword is shorthand that tells the command to look up the default netmask for the specified subnet in the file /etc/inet/netmasks . The file has entries like the following: #subnet netmask 192.168.9.0 255.255.255.0 5.2.1.4 Interface configuration at boot timeTable 5-8 lists the configuration files that store the parameters for ifconfig for each Unix version we are considering and also provides some example entries from the file, using the first interface of a common type. The third column in the table indicates which boot script actually performs the interface configuration operation and where in the boot process it occurs.
These files and their entries are quite straightforward and self-explanatory. Multiple interfaces are configured in the same manner. Parameters for additional interfaces are defined in the same way as the first one, typically using the next element in the array (e.g., IP_ADDRESS[1] (HP-UX), NETDEV_1 (Tru64), and the like), corresponding syntax (e.g., ifconfig_xl1 for FreeBSD), or an analogous filename (e.g., hostname.hme1 for Solaris or ifcfg_eth1 for Linux). The Solaris /etc/hostname. interface (where interface is the interface name, e.g., hme0) file merits additional comment. In general, this file requires only a hostname as its contents, but you can also place specific parameters to ifconfig on additional lines if desired, as in this example: kali 192.168.24.37 netmask 255.255.248.192 broadcast 192.168.191.255 Generally, Solaris attempts to locate the system's IP address automatically by consulting all the available name services, but you can specify specific parameters in this way if you choose. The /etc/init.d/network script will append each additional line in turn to ifconfig interface inet to form a complete command, which is then executed immediately. The hostname still needs to be the first line in the file or other parts of the script will break.
5.2.2 Dynamic IP Address Assignment with DHCPThe Dynamic Host Configuration Protocol (DHCP) facility is used to dynamically assign IP addresses and configuration settings to network hosts.[17] This facility is designed to decrease the amount of individual workstation configuration necessary for a system to be successfully connected to the network. It is especially suited to computer systems that change network locations frequently (e.g., laptops).
The DHCP facility assigns an IP address to a requesting host for a specified period of time known as a lease, via a process like the following:
As this description indicates, the DHCP facility depends heavily on broadcast messages, but it does not generate an inordinate amount of network traffic if it is configured properly. Typical default lease periods are a few hours, but the time period can be shortened or lengthened as appropriate (see Section 8.3). DHCP can also be used to assign other parameters related to networking to the client, including the default gateway (router), the hostname, and which server(s) to use for a variety of functions, including DNS, syslog message destination, X fonts, NTP, and so on. In addition, DHCP clients can request that specific parameters be supplied by the server and optionally reject offers that do not fulfill them. Some clients can also specify terms for the lease, such as the time period. DHCP additional parameters are known as options, and they are identified via standard identifying numbers. In the remainder of this section, we'll look at configuring DHCP clients. We'll discuss DHCP servers in Chapter 8. Table 5-9 summarizes the various files and settings involved in DHCP client configuration on the various systems we are considering, using the first Ethernet interface of a common type as an example in each case. The table is followed by discussions of the specifics for each Unix version.
5.2.2.1 AIXThe easiest way to enableDHCP on an AIX system is to use SMIT, specifically the smit usedhcp command. The resulting dialog is illustrated in Figure 5-6. Figure 5-6. Enabling DHCP with SMITAs the figure illustrates, SMIT allows you not only to enable DHCP but also to specify a desired lease length and other DHCP parameters. In this example, we request a lease length of 30,000 seconds (5 hours), and we also specify a specific DHCP server to contact (giving its IP address and subnet mask). This second item is not necessary and in fact is usually omitted; it is included here only for illustrative purposes. AIX DHCP client configuration consists of three parts:
5.2.2.2 FreeBSDFreeBSD uses the DHCP implementation created by the Internet Software Consortium (ISC). The dhclient command requests DHCP services when they are needed. At boot time, it is called from rc.network. It uses the configuration file, /etc/dhclient.conf. Here is a simple example: interface "xl0" { request subnet-mask, broadcast-address, host-name, time-offset, routers, domain-name, domain-name-servers; require subnet-mask; send requested-lease-time 360000; media "media 10baseT/UTP", "media 10base2/BNC"; } This file configures DHCP for the interface xl0, for which DHCP is enabled in /etc/rc.conf (ifconfig_xl0='DHCP'). This example specifies a list of options for which to request values from the DHCP server. Leases without most of these options will still be acceptable, but the subnet mask parameter is required. The client also requests a lease time of 360,000 seconds (100 hours). All the items within the braces apply only to this particular interface. However, these same commands can appear independently within the configuration file, in which case they apply to all specified interfaces. Many other options are provided, including the ability to specify a specific DHCP server. NOTE
The default version of /etc/dhclient.conf usually works fine unmodified. 5.2.2.3 HP-UXOnce DHCP has been enabled for an interface in /etc/rc.config.d/netconf, it will be started at boot time automatically. The auto_parms script is called from /etc/rc, and it performs the actual DHCP operations, with help from set_parms. The script also calls dhcpdb2conf, which merges the configuration data provided by DHCP into the network configuration file mentioned above, and the ifconfig process proceeds in the same way it does for hosts with static IP addresses. In addition, auto_parms starts the dhcpclient daemon, which oversees the lease and its renewal. Other than enabling DHCP for the network interface, HP-UX provides nothing in terms of DHCP client configuration. When you enable DHCP, you will also need to set the corresponding IP_ADDRESS and SUBNET_MASK variables to an empty string. 5.2.2.4 LinuxDHCP configuration differs slightly among different Linux distributions. However, both Red Hat and SuSE use the file ifcfg.eth0 to hold configuration information for the first Ethernet interface (see Table 5-8 for the directory locations), and DHCP is enabled in this file as well, via the BOOTPROTO parameter. The actual interface configuration happens in the /etc/init.d/network boot script, which is called during a boot, during the transition to run level 2. On both systems, the network script calls additional scripts and commands to help it perform its tasks. The most important of these is /sbin/ifup which is responsible for network interface activation both for systems with static IP addresses and for DHCP clients. On Red Hat Linux systems, ifup starts the dhcpcd daemon, which monitors and renews the DHCP lease as necessary. On SuSE Linux systems, it calls another command, ifup-dhcp (also in /sbin) to perform the core configuration tasks, including starting the daemon. On SuSE systems, there is also another option for DHCP clients: the dhclient command, part of the same Internet Software Consortium (ISC) DHCP implementation used by FreeBSD. It uses a similar /etc/dhclient.conf configuration file to the one described above for FreeBSD. The default on SuSE systems is to use dhcpcd, but dhclient can be selected using the following entry in the /etc/sysconfig/network/dhcp configuration file: DHCLIENT_BIN="dhclient" On older Red Hat systems, the default DHCP client is pump . This facility is still available as an option if you want to use it (currently, it is not included in an installation unless you specifically request it). 5.2.2.5 SolarisOn aSolaris system, you can specify that a network interface be configured using DHCP by issuing a command like the following: # ifconfig hme0 dhcp (You can change back to a static configuration by adding drop to this command.) Initiating DHCP in this way automatically invokes the dhcpagent daemon. It will initiate and manage the DHCP lease. For an interface to be configured with DHCP at boot time, a file of the form /etc/dhcp.interface must exist. Such files can be empty. If one of these files contains the word "primary" as its contents, the corresponding interface will be configured first (if more than one includes the word "primary," the first one listed in the file will be used as the primary interface). The dhcpagent daemon uses the configuration file /etc/default/dhcpagent. The following is the most important entry within it: PARAM_REQUEST_LIST=1,3,12,43 This entry specifies the list of parameters that the client will request from the DHCP server. The standard DHCP parameter numbers are translated to descriptive strings in the /etc/dhcp/inittab file. 5.2.2.6 Tru64Tru64 also uses a daemon to manage DHCP client leases. Its name is joinc, and it is started at boot time by the dhcpconf command; the latter is invoked by /sbin/init.d/inet when moving to run level 3. The DHCP client configuration file is /etc/join/client.pcy Here is a simple example of this file: use_saved_config Use existing lease if still valid. lease_desired 604800 One week lease. # options to request from server request broadcast_address request dns_servers request dns_domain_name request routers request host_name request lease_time The bulk of this file consists of a list of options to be requested from the server. The full list of supported options is given in the client.pcy manual page. 5.2.3 Name Resolution OptionsThe term name resolution refers to the process of translating a hostname to its corresponding IP address. Hostnames are much more convenient for users and administrators within commands and configuration files, but actual network operations require IP addresses.[20] Thus, when a user enters a command like finger chavez@hamlet, one of the first things that must happen is that the hostname hamlet gets translated to its IP address (say, 192.168.2.6). There are several ways that this can happen, but the two most prevalent are:
In the first case, the hostnames and IP addresses of all hosts with which the local host will need to communicate must be entered into /etc/hosts (or another central location). In the second case, a host trying to translate a name will contact a local or remote named server process to determine the corresponding IP address. For a relatively small network not on the Internet, using just /etc/hosts may not be a problem. For even a medium-sized network, however, this strategy may result in a lot of work every time a new host is added, because the master hosts file must be propagated to every system in the network. For networks on the Internet, using DNS is the only practical way to translate hostnames for systems located beyond the local domain. 5.2.3.1 The /etc/hosts fileThe file /etc/hosts traditionally contains a list of the hosts in the local network (including the local host itself). If you use this file for name resolution, whenever you add a new system to the network, you will have to edit it on (or copy a master version to) every system on the Unix local network (and take whatever action is equivalent for hosts running other operating systems).
Here is a sample /etc/hosts file for a small LAN: # Loopback address for localhost 127.0.0.1 localhost # Local hostname and address 192.168.1.2 spain # Other hosts 192.168.1.3 usa 192.168.1.4 canada england uk 192.168.1.6 greece olympus 10.154.231.42 paradise Lines beginning with # are comments and are ignored. Aside from the comments, each line has three fields: the IP address of a host in the network, its hostname, and any aliases (synonyms) for the host. Every /etc/hosts file should contain at least two entries: the loopback address and the address by which the local system is known to the rest of the network. The remaining lines describe the other hosts in your local network. This file may also include entries for hosts that are not on your immediate local network. On Solaris systems, the hosts file has moved to the /etc/inet directory (as have several other standard network configuration files), but a link to the standard location is provided. 5.2.3.2 Configuring a DNS clientOn the client side, DNS configuration is very simple and centers around the /etc/resolv.conf configuration file. This file lists the local domain name and the locations of one or more name servers to be used by the local system. Here is a simple resolver configuration file: search ahania.com DNS domains to search for names. nameserver 192.168.9.44 nameserver 192.168.10.200 The first entry specifies the DNS domain(s) in which to search for name translations. Up to six domains can be specified (separated by spaces), although listing only one is quite common. In general, they should be ordered from most to least specific (e.g., subdomains before their parent domain). On some systems, domain will replace the search keyword in the installed configuration file version; this is an older resolver configuration convention, and such entries are used to specify only the name of the local domain (i.e., a list is not accepted). Name servers are identified by IP address, and up to three may be listed. When a name server needs to be located, they are contacted in the order in which they are listed in the file. However, once a server has successfully replied to a query, it will continue to be used. Thus, the best practice is to place servers in preferential order within this file. Usually, this means from closest to most distant, but when there are multiple local name servers, clients are generally configured so that each server is preferred by the appropriate fraction of clients (e.g., half of the clients in the case of two local name servers). There are two other configuration file entries which are useful in some special circumstances:
On most systems, removing (or renaming) /etc/resolv.conf will disable DNS lookups from the system. 5.2.3.3 The name service switch fileSome operating systems, including Linux, HP-UX, and Solaris, provide an additional configuration file relevant to DNS clients, /etc/nsswitch.conf . This name service switch file enables the system administrator to specify which of the various name resolution services are to be consulted when a hostname needs to be translated, as well as the order in which they are called. Here is an example: hosts: files dns This entry says to consult /etc/hosts first when attempting to resolve a hostname, and to use DNS if the name is not present in the file. In fact, the file contains similar entries for many networking functions, as these entries illustrate: passwd: files nis services: files The first entry says to consult the traditional password file when looking for user account information and then to consult the Network Information Service (NIS) if the account is not found in /etc/passwd. The second entry says to use only the traditional file for definitions of network services. This sort of construct is also frequently used in nsswitch.conf: passwd: nis [NOTFOUND=return] files This entry says to contact NIS for user account information. If the required information is not found there, the search will stop (the meaning of return), and cause the originating command to fail with an error. The traditional password file is used only when the NIS service is unavailable (e.g., at boot time). The other operating systems we are considering offer similar facilities. Currently, FreeBSD provides the /etc/host.conf file, which looks like this: hosts FreeBSD 4 resolver order configuration bind This file says to look in the hosts file first and then to consult DNS. Older versions of Linux also used this file, with a slightly different syntax: order hosts,bind Linux host.conf syntax AIX uses the /etc/netsvc.conf file for the same purpose. Here is an example which sets the same order as the preceding: hosts = local, bind AIX resolver order configuration Finally, Tru64 uses the /etc/svc.conf file, as in this example: hosts=local,bind Tru64 resolver order configuration The AIX and Tru64 file also contain entries for other system and network configuration files. 5.2.4 Routing OptionsAs with hostname resolution, there are a number of options for configuring routing within a network:
Static routing relies on the route command. Here are some examples of its use: # route add 192.168.1.12 192.168.3.100 # route add -net 192.168.2.0 netmask 255.255.255.0 192.168.3.100 The first command adds a static route to the host 192.168.1.12, specifying host 192.168.3.100 as the intermediate point (gateway). The second command adds a route to the subnet 192.168.2 (recall that host 0 refers to a network itself), via the same gateway. The command form is slightly different under FreeBSD, Solaris, and AIX (note the hyphen used with the netmask keyword): # route add -net 192.168.2.0 -netmask 255.255.255.0 192.168.3.100 Linux uses a slightly different form for the route command: # route add -net 10.1.2.0 netmask 255.255.240.0 gw 10.1.3.100 The gw keyword is required. The command form route add default is used to define a default gateway. All non-local packets for which there is not an explicit route in the routing table are sent to this host for forwarding. NOTE
For many client systems, defining the default gateway will be all the routing configuration that is necessary. The command netstat -r may be used to display therouting tables. Here is the output from a Solaris system named kali: # netstat -r Routing Table: IPv4 Destination Gateway Flags Ref Use Interface ------------- -------------- ----- ----- ------ --------- 192.168.9.0 kali U 1 4 hme0 default suzanne UG 1 0 localhost localhost UH 3 398 lo0 The first line in the output's table of routes specifies the route to the local network, through the local host itself. The second line specifies the default route for all traffic destined beyond the local subnet; here, it is the host named suzanne. The final line specifies the route used by the loopback interface to redirect packets to the local host. Use the -n option to view IP addresses rather than hostnames. This can be useful when there are DNS problems. To remove a route, replace the add keyword with delete: # route delete -net 192.168.1.0 netmask 255.255.255.0 192.168.2.100 The Linux version of the route command will also display the current routing tables when executed without arguments. The AIX, FreeBSD, Solaris, and Tru64 versions ofroute also provide a change keyword for modifying existing routes (e.g., to change the gateway). These versions also provide a flush keyword for removing all routes to remote subnets from the routing table in a single operation; HP-UX provides the same functionality with route's -f option. All the operating systems provide mechanisms for specifying a list of static routes to be set up each time the system boots. The various configuration files are summarized in the sections that follow. 5.2.4.1 AIXOn AIX systems, static routes are stored in the ODM. You can use the smit mkroute command to add one or simply issue a route command. The results of the latter persist across boots. 5.2.4.2 FreeBSDFreeBSD stores static routes in the /etc/rc.conf and/or /etc/rc.conf.local configuration files. Here are some examples of its syntax for these entries: defaultrouter="192.168.1.200" static_routes="r1 r2" route_r1="-net 192.168.13.0 192.168.1.49" route_r2="192.168.99.1 192.168.1.22" The first entry specifies the default gateway for the local system. The second line specifies labels of the static routes that should be created at boot time. Each label refers to a route_ entry later in the file. The latter hold the arguments and options to be passed to the route command. 5.2.4.3 HP-UXStatic routes are defined in /etc/rc.config.d/netconf onHP-UX systems, via entries like these, which define the default gateway for this system: ROUTE_DESTINATION[0]=default ROUTE_MASK[0]="255.255.255.0" ROUTE_GATEWAY[0]=192.168.9.200 ROUTE_COUNT[0]=1 Total number of static routes. ROUTE_ARGS[0]="" Additional arguments to the route command. Additional static routes can be defined by increasing the value of the route count parameter and adding additional entries to the array (i.e., [1] would indicate the secondstatic route). 5.2.4.4 LinuxLinux systems generally list the static routes to be created at boot time in a configuration file in or under /etc/sysconfig. On Red Hat systems, this file is named static-routes. Here is an example: #interface type destination gw ip-address eth0 net 192.168.13.0 gw 192.168.9.49 any host 192.168.15.99 gw 192.168.9.100 The first line specifies a route to the 192.168.13 network via the gateway 192.168.9.49, limiting it to the eth0 interface. The second line specifies a route to the host 192.168.15.99 via 192.168.9.100 (valid for any network interface). On Red Hat systems, the default gateway is defined in the network configuration file in the same directory: GATEWAY=192.168.9.150 SuSE Linux uses the file /etc/sysconfig/network/routes to define both the default gateway and static routes. It contains the same information as the Red Hat version, but it uses a slightly different syntax: # Destination Gateway Netmask Device 127.0.0.0 0.0.0.0 255.255.255.0 lo 192.168.9.0 0.0.0.0 255.255.255.0 eth0 default 192.168.9.150 0.0.0.0 eth0 192.168.13.0 192.168.9.42 255.255.255.0 eth0 The first two entries specify the routes for the loopback interface and for the local network (the latter is required on Linux systems, in contrast to most other Unix versions). The third entry specifies the default gateway, and the final entry defines a static route to the 192.168.13 subnet via the gateway 192.168.9.42. 5.2.4.5 SolarisSpecifying the default gateway underSolaris is very easy. The file /etc/defaultrouter contains a list of one or more IP addresses (on separate lines) corresponding to systems/devices that serve as default gateways for the local system.
There is no built-in mechanism for specifying additional static routes to be added at boot time. However, you can create a script containing the desired commands and place it in (or link it to) the /etc/rc2.d directory (or rc3.d if you prefer). 5.2.4.6 Tru64Tru64 lists static routes in the file /etc/routes . Here is an example: default 192.168.9.150 -net 192.168.13.0 192.168.10.200 Each line of the file is passed as the arguments to the route command. The first entry in the example file illustrates the method for specifying the default gateway for the local system. |