5.2 Adding a New Network Host

To add a new host to thenetwork, you must:

  • Install networking software and build a kernel capable of supporting networking and the installed networking hardware (if necessary). These days, basic networking is almost always installed by default with the operating system, but you may have to add some features manually.

  • Physically connect the system to the network and enable the hardware network interface. Occasionally, on older PC systems, the latter may involve setting jumpers or switches on the network adapter board or setting low-level system parameters (usually via the pre-boot monitor program).

  • Assign a hostname and network address to the system (or find out what has been assigned by the network administrator). When you add a new host to an existing network, the unique network address you assign it must fit in with whatever addressing scheme is already in use at your site. You can also decide to use DHCP to assign the IP address and other networking parameters dynamically instead of specifying a static address.

  • Ensure that necessary configuration tasks occur at boot time, including starting all required networking-related daemons.

  • Configure name resolution (hostname-to-IP address translation).

  • Set up any static routes and configure any other routing facilities in use. This includes defining a default gateway for packets destined beyond the local subnet.

  • Test the network connection.

  • Enable and configure any additional network services that you plan to use on that computer.

5.2.1 Configuring the Network Interface with ifconfig

The 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 netmask

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 Ethernet interface names

The 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]

[16] AIX uses different interface names for other networking types: et0 for so-called 803.2 (a related but slightly different protocol), tr0 for Token Ring etc.

xl0, de0, and others (depends on hardware)
hme0, dnet0, eri0, le0
tu0, ln0 Other uses of ifconfig

Without 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 netmask 0xffffff00 broadcast

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. ifconfig on Solaris systems

Solaris 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 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 Interface configuration at boot time

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

Table 5-8. Boot-time network interface configuration

Unix version

Configuration file

Boot script (Invoked by)


Data is stored in the ODM; use smit mktcpip or the mktcpip command to modify it (not ifconfig commands).

/sbin/rc.boot (first /etc/inittab entry)



hostname="clarissa" ifconfig_xl0=" netmask"

/etc/rc.network (called from /etc/rc)




/sbin/init.d/net (link in /sbin/rc2.d)

Linux (Red Hat)





/etc/init.d/network (link in /etc/rc2.d)

Linux (SuSE 7)


NETCONFIG="_0"     Number of interfaces IPADDR_0="" NETDEV_0="eth0" IFCONFIG_0=" broadcast netmask"



/etc/init.d/network (link in /etc/rc2.d)

Linux (SuSE 8)





/etc/init.d/network (link in /etc/rc2.d)




/etc/init.d/network (link in /sbin/rcS.d)



HOSTNAME="ludwig" NETDEV_0="tu0" IFCONFIG_0=" netmask" NUM_NETCONFIG="1"     Number of interfaces export HOSTNAME NETDEV_0  . . . 

/sbin/init.d/inet (link in /sbin/rc3.d)

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 netmask broadcast

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.

The file /etc/nodename also contains the hostname of the local host; it is used when the system is in standalone mode and in other circumstances within the boot scripts. If you decide to change a system's hostname, you'll need to change it in both /etc/nodename and the /etc/hostname.* file (as well as in /etc/hosts, DNS and any other directory service you may be running).

5.2.2 Dynamic IP Address Assignment with DHCP

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

[17] DHCP is a follow-on to the BOOTP remote booting facility.

Never use dynamic addressing for any system that shares any of its resources filesystems (via NFS or SAMBA), printers, or other devices or provides any network resources (DNS, DHCP, electronic mail services, and so on). It is OK to use DHCP to assign static addresses to servers (see Section 8.3).

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:

  • The requesting (client) system broadcasts a DHCP Discover[18] message to UDP port 67. At this point, the system does not need to know anything about the local network, not even the subnet mask (the source address for this message is, and the destination is

    [18] More precisely, it is a DHCPDISCOVER message, but I've tried to make the text more readable by adding a space and changing letter case.

  • One or more DHCP servers reply with a DHCP Offer message (to UDP port 68), containing an IP address, subnet mask, server IP address, and lease duration (and possibly other parameters). The server reserves the offered address until it is accepted or rejected by the requesting client or a timeout period expires.

  • The client selects an offered IP address and broadcasts a DHCP Request message. All servers other than the successful one release the pending reservation.

  • The selected server sends a DHCP Acknowledge message to the client.[19]

    [19] Occasionally, things don't work out after an offer has been selected. The server also has the option of sending a Negative Acknowledgement if there is some problem with the request. Also, the client can send a Decline message to the server if its initial test of the IP address fails. In either case, the client restarts the discovery process from the beginning.

  • When the lease is 50% expired, the client attempts to renew it (via another DHCP Request). If it cannot do so at that time, it will tries when it reaches 87.5% of the lease period; if the second renewal attempt also fails, the client looks for a new server. During the lease period, DHCP-assigned parameters persist across boots on most systems. On some systems, the client tries to extend its lease each time it boots.

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.

Table 5-9. DHCP client configuration summary


Location and/or configuration

Enable DHCP


ODM; interface stanza (/etc/dhcpcd.ini)


ifconfig_xl0="DHCP" (/etc/rc.conf)


DHCP_ENABLE=1 (/etc/rc.config.d/netconf)


IFCONFIG_0="dhcpclient" in /etc/rc.config (SuSE 7); BOOTPROTO='dhcp' (ifcfg_eth0 in /etc/sysconfig/network-scripts in Red Hat, /etc/sysconfig/network in SuSE 8)


Create /etc/dhcp.hme0


IFCONFIG_0="DYNAMIC" (/etc/rc.config)

Additional Configuration Files







Primary Command orDaemon


dhcpcd daemon


dhclient command


dhcpclient daemon


dhcpcd daemon


dhcpagent daemon


joinc daemon

Boot Script where DHCP Configuration Occurs













Automated/ Graphical Configuration Tool


smit usedhcp






Linuxconf (Red Hat), YAST2 (SuSE)


Solaris Management Console



Current Lease Information








/etc/dhcp/dhcpcd-eth0.info (Red Hat); /var/lib/dhcpcd/dhcpcd-eth0.info (SuSE)




/etc/join/leases AIX

The 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 SMIT

As 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:

  • Configuring and starting the dhcpcd daemon, which requests configuration information and keeps track of the lease status. In particular, the relevant lines in /etc/rc.tcpip must be activated by removing the initial comment marker:

    # Start up dhcpcd daemon start /usr/sbin/dhcpcd "$src_running"
  • Adding a stanza for the network interface and other settings to dhcpcd's config file /etc/dhcpcd.ini . Here is an example of this file:

    # Use 4 log files of 500KB each and log lots of info numLogFiles     4 logFileSize     500 logFileName     /usr/tmp/dhcpcd.log logItem         SYSERR logItem         OBJERR logItem         WARNING logItem         EVENT logItem         ACTION  updateDNS "/usr/sbin/dhcpaction '%s' '%s' '%s' '%s' A NONIM    >> /tmp/updns.out 2> &1 "    Command is wrapped. clientid MAC    Identify client via its MAC address. interface en0 { option 12 "lovelace"    Hostname. option 51 30000    Requested lease period in seconds.  . . .  }

    The first section of the file specifies desired logging options. Here we request substantial detail by selecting five types of events to log. The next section includes a command to be used for updating DNS with the IP address assigned to this host (changing this command is not recommended). The final section specifies the configuration for the en0 interface. The items between the curly braces set values for various DHCP options. (The file /etc/options.file defines DHCP option numbers.)

  • Setting parameters within the interface's record in the ODM. This step can be accomplished via SMIT or manually, using the mktcpip command. FreeBSD

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



The default version of /etc/dhclient.conf usually works fine unmodified. HP-UX

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

DHCP 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:


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

On 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:


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

Tru64 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 Options

The 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, There are several ways that this can happen, but the two most prevalent are:

[20] And, ultimately, MAC addresses.

  • The IP address can be looked up in a file. The list of translations is traditionally stored in /etc/hosts. When a directory service is in use, the contents of the local hosts file may be integrated into it, and a common master file can be automatically propagated throughout a network (e.g., NIS).

  • The client can contact a Domain Name System (DNS) server and ask it to perform the translation.

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. The /etc/hosts file

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

Even systems that use DNS for name resolution typically have a small hosts file for use during booting.

Here is a sample /etc/hosts file for a small LAN:

# Loopback address for localhost     localhost    # Local hostname and address   spain    # Other hosts    usa    canada england uk    greece olympus  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. Configuring a DNS client

On 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 nameserver

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:

sortlist network-list

This entry specifies how to select among multiple responses that may be returned by a DNS query when the target has multiple network interfaces.

options ndots :n

This entry determines when the domain name will be automatically added to a hostname. The domain name will be added only when the target name has less than n periods within it. The default for n is 1, causing the domain name to be added only to bare hostnames.

On most systems, removing (or renaming) /etc/resolv.conf will disable DNS lookups from the system. The name service switch file

Some 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 Options

As with hostname resolution, there are a number of options for configuring routing within a network:

  • If the LAN consists of a single Ethernet network not connected to any other networks, no explicit routing is usually needed (since all hosts are visible and adjacent to all others). The ifconfig commands used to configure the network interfaces will usually provide them with enough information for them to route packets to their destination.

  • Static routing may be used for small- to medium-sized networks not characterized by many redundant paths to most destinations. This is set up by explicit route commands that are executed at boot time.

  • Dynamic routing, in which optimal paths to destinations are determined at packet transmission time, may be used via the routed or gated daemon. They are discussed in Section 8.2.

Static routing relies on the route command. Here are some examples of its use:

# route add # route add -net netmask

The first command adds a static route to the host, specifying host 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 -netmask

Linux uses a slightly different form for the route command:

# route add -net netmask gw

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.



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

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

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

FreeBSD 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="" static_routes="r1 r2" route_r1="-net" route_r2=""

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

Static 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]="" ROUTE_GATEWAY[0]= 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). Linux

Linux 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   gw any         host  gw

The first line specifies a route to the 192.168.13 network via the gateway, limiting it to the eth0 interface. The second line specifies a route to the host via (valid for any network interface).

On Red Hat systems, the default gateway is defined in the network configuration file in the same directory:


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       lo       eth0 default             eth0      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 Solaris

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

Be aware that you need to create this file yourself. It is not created as part of the installation process.

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

Tru64 lists static routes in the file /etc/routes . Here is an example:

default -net

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.

Essential System Administration
Essential System Administration, Third Edition
ISBN: 0596003439
EAN: 2147483647
Year: 2002
Pages: 162

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net