 | Chapter 6 |  |
| Chapter 6 | |
When networking protocols work only with a single kind of physical network, there is no need to identify the network interface to the software. The software knows what the interface must be; no configuration issues are left for the administrator. However, one important strength of TCP/IP is its flexible use of different physical networks. This flexibility adds complexity to the system administrator's task, because you must tell TCP/IP which interfaces to use, and you must define the characteristics of each interface.
Because TCP/IP is independent of the underlying physical network, IP addresses are implemented in the network software - not in the network hardware. Unlike Ethernet addresses, which are determined by the Ethernet hardware, the system administrator assigns an IP address to each network interface.
In this chapter, we use the ifconfig (interface configure) command to identify the network interface to TCP/IP and to assign the IP address, subnet mask, and broadcast address to the interface. We also configure a network interface to run Point-to-Point Protocol (PPP), which is the standard Network Access Layer protocol used to run TCP/IP over modem connections. Let's begin with a discussion of ifconfig.
The ifconfig command sets, or checks, configuration values for network interfaces. Regardless of the vendor or version of UNIX, the ifconfig command will set the IP address, the subnet mask, and the broadcast address for each interface. Its most basic function is assigning the IP address.
Here is the ifconfig command that configures the Ethernet interface on peanut:
#ifconfig le0 172.16.12.2 netmask 255.255.255.0 \ broadcast 172.16.12.255
Many other arguments can be used with the ifconfig command; we discuss several of these later. But a few important arguments provide the basic information required by TCP/IP for every network interface. These are:
The name of the network interface that you want to configure for TCP/IP. In the example above, this is the Ethernet interface le0.
The IP address assigned to this interface. Enter the address as either an IP address (in dotted decimal form) or as a hostname. If you use a hostname, place the hostname and its address in the /etc/hosts file. Your system must be able to find the hostname in /etc/hosts because ifconfig usually executes before DNS is running. The example uses the numeric IP address 172.16.12.2 as the address value.
The subnet mask for this interface. Ignore this argument only if you're using the default mask derived from the traditional address class structure. If you are subnetting, use your subnet mask. The subnet mask chosen for our imaginary network is 255.255.255.0, so that is the value assigned to peanut's le0 interface. See Chapters 2 and 4 for information on address masks and subnets.
The broadcast address for the network. Most, but not all, systems default to the standard broadcast address, which is an IP address with all host bits set to 1. In the ifconfig example we explicitly set the broadcast address to 172.16.12.255 to avoid any confusion. Every system on the subnet must agree on the broadcast address.
The network administrator provides the values for the address, subnet mask, and broadcast address. The values in our example are taken directly from the planning sheet we developed in Chapter 4, Getting Started . But the name of the interface, the first argument on every ifconfig command line, must often be determined from the system's documentation.
In Chapter 5, Basic Configuration , we saw that Ethernet network interfaces come in many varieties, and that different Ethernet cards usually have different interface names. You can usually determine which interface is used on a system from the messages displayed on the console during a boot. On many systems these messages can be examined with the dmesg command. But even with this information, determining the name of the Ethernet interface is not always easy. The following example shows the output of the dmesg command on two different systems:
almond%dmesg | grep le0le0 at ledma0: SBus slot f 0xc00000 sparc ipl 6 le0 is /iommu@f,e0000000/sbus@f,e0001000/ledma@f,400010/le@f,c00000 acorn>dmesg | grep eth0eth0: smc8432 (DEC 21041 Tulip) at 0xfc80, 00:00:c0:dd:d4:da, IRQ 10 eth0: enabling 10TP port.
The first dmesg command in the example shows the messages displayed when an le0 Ethernet interface is detected during the boot of a Solaris 2.5.1 system. Nothing about these messages makes it clear that le0 is an Ethernet interface. The second dmesg example, which comes from a PC running Linux, provides more clues. eth0 is a more intuitive Ethernet interface name; and the Linux system displays the Ethernet address (00:00:c0:dd:d4:da) and the make and model (SMC8432) of the network adapter card. If you know what these things mean, it makes guessing the Ethernet interface name simpler.
It is not always easy to determine all available interfaces on your system by looking at the output of dmesg, nor by looking at device statements in the kernel configuration file. These only show you the physical hardware interfaces. In the TCP/IP protocol architecture, the Network Access Layer encompasses all functions that fall below the Internet Layer. This can include all three lower layers of the OSI Reference Model: the Physical Layer, the Data Link Layer, and the Network Layer. IP needs to know the specific interface in the Network Access Layer where packets should be passed for delivery to a particular network. This interface is not limited to a physical hardware driver. It could be a software interface into the network layer of another protocol suite. So what other methods can help you determine the network interfaces available on a system? Use the netstat and the ifconfig commands. For example, to see all network interfaces that are already configured, enter:
%netstat -in
The -i option tells netstat to display the status of all configured network interfaces, and the -n tells netstat to display its output in numeric form. The netstat -in command displays the following fields:
The Interface Name field shows the actual name assigned to the interface.
This is the name you give to ifconfig to identify the
interface. An asterisk (*)
in this field indicates that the
interface is not enabled; i.e., the interface is not "up."
The Maximum Transmission Unit shows the longest frame (packet) that can be transmitted by this interface without fragmentation. The MTU is displayed in bytes. MTU is discussed in the section "The datagram" in Chapter 1, Overview of TCP/IP.
The Network/Destination field shows the network or the destination host to which the interface provides access. In our Ethernet examples, this field contains a network address. The network address is derived from the IP address of the interface and the subnet mask. This field contains a host address if the interface is configured for a point-to-point (host-specific) link. The destination address is the address of the remote host at the other end of the point-to-point link. [1] A point-to-point link is a direct connection between two computers. You can create a point-to-point link with the ifconfig command. How this is done is covered later in this chapter.
[1] See the description of the H flag in the section "Routing Table" in Chapter 2, Delivering the Data.
The IP Address field shows the Internet address assigned to this interface.
The Input Packets field shows how many packets this interface has received.
The Input Errors field shows how many damaged packets the interface has received.
The Output Packets field shows how many packets were sent out by this interface.
The Output Errors field shows how many of the packets caused an error condition.
The Collisions field shows how many Ethernet collisions were detected by this interface. Ethernet collisions are a normal condition caused by Ethernet traffic contention. This field is not applicable to non-Ethernet interfaces.
The Packets Queued field shows how many packets are in the queue, awaiting transmission via this interface. Normally this is zero.
The output of a netstat command shows:
%netstat -inName Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue le0 1500 172.16.0.0 172.16.12.2 1547 1 1127 0 135 0 lo0 1536 127.0.0.0 127.0.0.1 133 0 133 0 0 0
This display shows that this workstation has only two network interfaces. In this case it is easy to identify each network interface. The lo0 interface is the loopback interface, which every TCP/IP system has. It is the same loopback device discussed in Chapter 5. le0 is a Lance Ethernet interface, also discussed in Chapter 5.
On most systems, the loopback interface is part of the default configuration, so you won't need to configure it. If you do need to configure lo0 on your system, use the following command:
#ifconfig lo0 127.0.0.1
The configuration of the Ethernet interface requires more attention. The surprising thing about the sample netstat display is that we haven't yet entered an ifconfig command for le0, and it already has an IP address! Many systems use an installation script to install UNIX. This script requests the host address, which it then uses to configure the interface. [2] Later we'll look at whether the user successfully set up this interface with the installation script.
[2] The netconfig command, discussed in Chapter 4, is an example of a network configuration script that runs when the operating system is installed.
The ifconfig command can also be used to find out what network interfaces are available on a system. The netstat command shows only interfaces that are configured. On some systems the ifconfig command can be used to show all interfaces, even those that have not yet been configured. On Solaris 2.5.1 systems, ifconfig -a does this; on a Linux 2.0.0 system, entering ifconfig without any arguments will list all of the network interfaces.
While most hosts have only one real network interface, some hosts and all gateways have multiple interfaces. Sometimes all interfaces are the same type; i.e., a gateway between two Ethernets may have two Ethernet interfaces. netstat on a gateway like this might display lo0, le0, and le1. Deciphering a netstat display with multiple interfaces of the same type is still very simple. But deciphering a system with many different types of network interfaces is more difficult. You must rely on documentation that comes with optional software to choose the correct interface. When installing new network software, always read documentation carefully.
This long discussion about determining the network interface may seem to overshadow the important ifconfig functions of assigning the IP address, subnet mask, and broadcast address. So let's return to these important topics.
As noted above, the UNIX installation script configures the network interface. However, this configuration may not be exactly what you want. Check the configuration of an interface with ifconfig. To display the current values assigned to the interface, enter ifconfig with an interface name and no other arguments. For example, to check interface le0:
%ifconfig le0le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 172.16.12.2 netmask ffff0000 broadcast 172.16.255.255
When used to check the status of an interface on a Solaris 2.5.1 system, the ifconfig command displays two lines of output. The first line shows the interface name, the flags that define the interface's characteristics, and the Maximum Transmission Unit (MTU) of this interface. In our example the interface name is le0, and the MTU is 1500 bytes. The flags are displayed as both a numeric value and a set of keywords. The interface's flags have the numeric value 863, which corresponds to:
The interface is enabled for use.
The interface supports broadcasts, which means it is connected to a network that supports broadcasts, such as an Ethernet.
This interface does not support trailer encapsulation. This is an Ethernet-specific characteristic which we discuss in more detail later.
This interface is operational.
The second line of ifconfig output displays information that
directly relates to TCP/IP. The keyword inet is followed by the
Internet address assigned to this interface. Next comes the keyword
netmask, followed by the address mask
written in hexadecimal. Finally,
the keyword broadcast and the broadcast address are displayed.
On a Linux system the ifconfig command displays up to six lines of information for each interface instead of the two lines displayed by the Solaris system. The additional information includes the Ethernet address, the PC IRQ and I/O Base Address, and packet statistics. The basic information is the same on both systems.
>ifconfig eth0eth0 Link encap:10Mbps Ethernet HWaddr 00:00:C0:9A:D0:DB inet addr:172.16.55.106 Bcast:172.16.55.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:844886 errors:0 dropped:0 overruns:0 TX packets:7668 errors:0 dropped:0 overruns:0 Interrupt:11 Base address:0x7c80
Refer to the Solaris ifconfig le0 example at the beginning of this section. Check the information displayed in that example against the configuration plan developed in Chapter 4. You'll see that the interface needs to be reconfigured. The configuration done by the user during the UNIX installation did not provide all of the values we planned. The address (172.16.12.2) is correct, but the address mask (ffff0000 or 255.255.0.0) and the broadcast address (172.16.0.0) are incorrect. Let's look at how these values are assigned, and how to correct them.
In order to function properly, every interface on a specific physical network segment must have the same subnet mask. For le0 on almond and peanut, the netmask value is 255.255.255.0, because both systems are attached to the same subnet. However, although almond's local network interface and its external network interface are parts of the same computer, they use different netmasks because they are on different networks.
To assign a subnet mask, write the subnet mask value after the keyword "netmask" on the ifconfig command line. The subnet mask is usually written in the "dotted decimal" form used for IP addresses. [3] For example, the following command assigns the correct subnet mask to the le0 interface on peanut:
[3] Hexadecimal notation can also be used for the subnet mask. To enter a netmask in hexadecimal form, write the value as a single hex number starting with a leading 0x. For example, the hexadecimal form of 255.255.255.0 is 0xffffff00. Choose the form that is easier for you to understand.
#ifconfig le0 172.16.12.2 netmask 255.255.255.0 \ broadcast 172.16.12.255
Putting the netmask value directly on the ifconfig command line is the most common, the simplest, and the best way to manually assign the subnet mask to an interface. But it is also possible to tell ifconfig to take the netmask value from a file instead of from the command line. Conceptually, this is similar to using a hostname in place of an IP address. The administrator can place the subnet mask value in either the hosts file or the networks file and then reference it by name. For example, the nuts-net administrator might add the following entry to /etc/networks:
nuts-mask 255.255.255.0
Once this entry has been added, you can use the name nuts-mask on the ifconfig command line, instead of the actual mask. For example:
#ifconfig le0 172.16.5.2 netmask nuts-mask
The name nuts-mask resolves to 255.255.255.0, which is the correct netmask value for our sample systems.
On Solaris systems, you can also use /etc/inet/netmasks to set the subnet mask. [4] The /etc/inet/netmasks file is a table of one-line entries, each containing a network address separated from a subnet mask by whitespace. [5] If a Solaris system on nuts-net (172.16.0.0) has a /etc/inet/netmasks file that contains the entry:
[4] /etc/netmasks is symbolically linked to /etc/inet/netmasks.
[5] Use the official network address, not a subnet address.
172.16.0.0 255.255.255.0
then the following ifconfig command can be used to set the subnet mask:
#ifconfig le0 172.16.5.1 netmask +
The plus sign after the keyword netmask causes ifconfig to take
the mask value from /etc/inet/netmasks. ifconfig searches
the file for a network address that matches the network address of the
interface being configured. It then extracts the subnet mask associated
with that address and applies it to the interface.
Some systems take advantage of the fact that the IP address, subnet mask, and broadcast address can be set indirectly to reduce the extent that startup files need to be customized. Reducing customization lessens the chance that a system might hang while booting because a startup file was improperly edited, and it makes it possible to pre-configure these files for all of the systems on the network. The hosts, networks, and netmasks files, which provide input to the ifconfig command, all produce NIS maps that can be centrally managed at sites using NIS.
A disadvantage of setting the ifconfig values indirectly is that it can make troubleshooting more cumbersome. If all values are set in the boot file, you only need to check the values there. When network configuration information is supplied indirectly, you may need to check the boot file, the hosts file, the networks file, and the netmasks file to find the problem. An error in any of these files could cause an incorrect configuration. To make debugging easier, many system administrators prefer to set the configuration values directly on the ifconfig command line.
Another disadvantage of setting the subnet mask value indirectly is that some of the files used for this are not primarily intended for this use. The hosts file is a particularly bad choice for storing subnet values. The hosts file is heavily used by other programs. Placing a subnet value in the hosts file might confuse one of these programs. Setting the subnet value directly on the command line or from a file, such as the netmasks file, that is dedicated to this purpose is probably the best approach.
RFC 919, Broadcasting Internet Datagrams, clearly defines the format of a broadcast address as an address with all host bits set to 1. Since the broadcast address is so precisely defined, ifconfig should be able to compute it automatically, and you should always be able to use the default. Unfortunately, this is not the case. TCP/IP was included in BSD 4.2 before RFC 919 was an adopted standard. BSD 4.2 used a broadcast address with all host bits set to 0, and didn't allow the broadcast address to be modified during configuration. Because of this history, some releases of UNIX default to a "0-style" broadcast address for compatibility with older systems, while other releases default to the standard "1-style" broadcast address.
Avoid this confusion by defining a broadcast address for the entire
network and ensuring that every device on the network explicitly sets it
during configuration. Set the broadcast address in the ifconfig
command using the keyword broadcast followed by the correct
broadcast address. For example, the ifconfig command to set the
broadcast address for almond's le0 interface is:
#ifconfig le0 172.16.12.1 netmask 255.255.255.0 \ broadcast 172.16.12.255
Note that the broadcast address is relative to the local subnet. almond views this interface as connected to network 172.16.12.0; therefore, its broadcast address is 172.16.12.255. Depending on the implementation, a UNIX system could interpret the address 172.16.255.255 as host address 255 on subnet 255 of network 172.16.0.0, or as the broadcast address for nuts-net as a whole. In neither case would it consider 172.16.255.255 the broadcast address for subnet 172.16.12.0.
We've used ifconfig to set the interface address, the subnet mask, and the broadcast address. These are certainly the most important functions of ifconfig, but it has other functions as well. It can enable or disable trailer encapsulation, the address resolution protocol, and the interface itself. ifconfig also can set the routing metric used by the Routing Information Protocol and the Maximum Transmission Unit (MTU) used by the interface. We'll look at each of these functions.
The ifconfig command has two arguments, up and down, for enabling and disabling the network interface. The up argument enables the network interface and marks it ready for use. The down argument disables the interface so that it cannot be used for network traffic.
Use the down argument when interactively reconfiguring an interface. Some configuration parameters - for example, the IP address - cannot be changed unless the interface is down. First, the interface is brought down. Then, the reconfiguration is done, and the interface is brought back up. For example, the following steps change the address for an interface:
#ifconfig le0 down#ifconfig le0 172.16.1.2 up
After these commands execute, the interface operates with the new configuration values. The up argument in the second ifconfig command is not actually required because it is the default. However, an explicit up is commonly used after the interface has been disabled, or when an ifconfig command is used in a script file to avoid problems if the default is changed in a future release.
Two options on the ifconfig command line, arp and trailers, are used only for Ethernet interfaces. The trailers option enables or disables negotiations for trailer encapsulation of IP packets. In Chapter 1, we discussed how IP packets are sent over different physical networks by being encapsulated in the frames that those networks transmit. Trailer encapsulation is an optional technique that reduces the number of memory-to-memory copies the receiving system needs to perform.
To enable trailer encapsulation, put the keyword trailers on the
ifconfig command line. When trailer encapsulation is enabled,
the system requests (via the ARP protocol) that other systems also use
trailer encapsulation when sending it data.
The option -trailers disables trailer encapsulation. Trailer encapsulation is disabled for two basic reasons. First, the I/O architecture of some systems does not derive any benefit from trailer encapsulation. If a system doesn't do memory-to-memory copies when receiving data from the network, it doesn't benefit from trailer encapsulation. Second, there are some systems that have difficulties with the negotiations for trailer encapsulation. For these reasons, many systems ignore the trailers argument and never use trailer encapsulation, and others allow trailer encapsulation but default to -trailers. Both of our sample systems, Solaris and Linux, ignore the trailers argument. However, some systems enable trailer encapsulation by default. Check your system documentation for the default on your system.
Chapter 2 discusses the Address Resolution Protocol (ARP),
an important protocol that maps IP addresses to physical Ethernet addresses.
Enable ARP with the ifconfig keyword arp and disable it with
the keyword -arp. It is possible (though very unlikely) that a host
attached to your network cannot handle ARP. This would only happen on a
network using specialized equipment or developmental hardware. In these
very rare circumstances, it may be necessary to disable ARP in order to
interoperate with the non-standard systems. By default, ifconfig enables ARP. Leave ARP enabled on all your systems.
On some systems, the ifconfig command creates an entry in the routing table for every interface that is assigned an IP address. Each interface is the route to a network. Even if a host isn't a gateway, its interface is still its "route" to the local network. ifconfig determines the route's destination network by applying the interface's subnet mask to the interface's IP address. For example, the le0 interface on almond has an address of 172.16.12.1 and a mask of 255.255.255.0. Applying this mask to the address provides the destination network, which is 172.16.12.0. The netstat -in display shows the destination address:
%netstat -inName Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue le0 1500 172.16.12.0 172.16.12.1 1125826 16 569786 0 8914 0 lo0 1536 127.0.0.0 127.0.0.1 94280 0 94280 0 0 0
The Routing Information Protocol (RIP) is a routing protocol commonly used by UNIX. RIP does two things: it distributes routing information to other hosts, and it uses incoming routing information to build routing tables dynamically. The routes created by ifconfig are one source of the routing information distributed by RIP, and the ifconfig metric argument can be used to control how RIP uses this routing information.
RIP makes routing decisions based on the cost of a route. The route's cost is determined by a routing metric associated with the route. A routing metric is just a number. The lower the number, the lower the cost of the route. The higher the number, the higher the cost. When building a routing table, RIP favors low-cost routes over high-cost routes. Directly connected networks are given a very low cost. Therefore, the default metric is 0 for a route through an interface to a directly attached network. However, you can use the metric argument to supply a different routing metric for an interface.
To increase the cost of an interface to three, so that RIP prefers routes with values of 0, 1, or 2, use metric 3 on the ifconfig command line:
#ifconfig std0 26.104.0.19 metric 3
Use the metric option only if there is another route to the same destination and you want to use it as the primary route. We did not use this command on almond, because it has only one interface connected to the outside world. But if it had a second connection, say, through a higher-speed link, then the command shown above could be used to direct traffic through the higher-performance interface.
A related ifconfig parameter is available on Solaris systems. RIP builds the routing table by choosing the most economical routes, and it distributes the routing table information to other hosts. The metric parameter controls which routes RIP selects as the lowest cost. The private argument, available on Solaris systems, controls the routes that RIP distributes. If private is specified on the ifconfig command line, the route created by that ifconfig command is not distributed by RIP. The default is -private, which permits the route to be distributed. The private parameter is not universally supported.
Additionally, not all systems make use of the metric argument. A Linux system doesn't create a routing table entry when it processes the ifconfig command. When configuring a Linux system, you add an explicit route command for each interface. (The route command is covered in the next chapter.) Linux systems ignore the metric argument.
Set the routing metric in a routing configuration file instead of on the ifconfig command line. This is the preferred method of providing routing information for newer routing software. We discuss the format of routing configuration files in the next chapter.
A network has a maximum transmission unit, which is the largest packet that can be transported over that physical network. On Ethernet, the maximum size is 1500 bytes, which is defined as part of the Ethernet standard. There is rarely any need to change the MTU on the ifconfig command line. By default, ifconfig chooses the optimum MTU, which is usually the largest legal MTU for a given type of network hardware. A large MTU is the default because it normally provides the best performance. However, a smaller MTU is helpful to achieve the following goals:
To avoid fragmentation. If the traffic travels from a network with a large MTU - such as an FDDI network with an MTU of 4500 bytes - through a network with a smaller MTU like an Ethernet, the smaller MTU size may be best in order to avoid packet fragmentation. It is possible that specifying an MTU of 1500 on the interface connected to the FDDI may actually improve performance by avoiding fragmentation in the routers. This would only be done if fragmentation actually appeared to be the cause of a performance problem.
To reduce buffer overruns or similar problems. On serial line connections it is possible to have equipment of such low performance that it cannot keep up with standard 1006-byte packets. In this case, it is possible to avoid buffer overruns or SILO overflows by using a smaller MTU. However, such solutions are temporary fixes. The real fix is to purchase the correct hardware for the application.
To change the MTU, use the mtu command-line argument:
# ifconfig fddi0 172.16.16.1 netmask 255.255.255.0 mtu 1500
This forces the FDDI interface on 172.16.16.1 to use an MTU of 1500 bytes.
There are probably several more ifconfig command-line arguments available on your system. Linux has parameters to define the PC interrupt of the Ethernet hardware (irq) and the Ethernet hardware address (hw), and to enable multicasting (multicast) and promiscuous mode (allmulti). Solaris has arguments to set up or tear down the streams for an interface (plumb/unplumb), and to use Reverse ARP (RARP) to obtain the IP address for an interface (auto-revarp). But most of these parameters are not standardized between versions of UNIX.
One last feature that is available on most versions of UNIX is the ability to define point-to-point connections with the ifconfig command. Point-to-point connections are network links that directly connect together only two computers. Of course the computers at either end of the link could be gateways to the world, but only two computers are directly connected to the link. Examples of a point-to-point connection are two computers linked together by a leased telephone line, or two computers in an office linked together by a null modem cable.
To define a point-to-point link on a Solaris system:
# ifconfig zs0 172.16.62.1 172.16.62.2
This ifconfig command has two addresses immediately following the interface name. The first is the address of the local host. The second address, called the destination address, is the address of the remote host at the other end of the point-to-point link. The second address shows up as the Net/Dest value in an netstat -ni display.
On a Linux system, this same configuration looks slightly different:
> ifconfig sl0 172.16.62.1 point-to-point 172.16.62.2
The syntax is different but the effect is the same. This enables the interface to run in point-to-point mode and identifies the hosts at both ends of the link.
Does this set up the Point-to-Point Protocol (PPP) used for TCP/IP serial line communication? No, it does not. These ifconfig parameters sometimes confuse people about how to set up PPP. There is much more to configuring PPP and SLIP, which we cover in the remainder of this chapter.
Before moving on to PPP and SLIP we should note that the configuration entered on an ifconfig command line will not survive a system boot. For a permanent configuration, put ifconfig in a startup file.
The ifconfig command is normally executed at boot time by a startup file. On BSD UNIX systems, the ifconfig commands are usually located in /etc/rc.boot or /etc/rc.local. System V UNIX presents a much more complex set of startup files, but the ifconfig statements are usually located in a file in the /etc/init.d directory. [6] On Linux systems, the startup files containing the ifconfig commands are usually in the /etc/rc.d or the /etc/rc.d/init.d directory. Use grep to locate the specific file that contains the ifconfig command:
[6] A good description of the maze of System V initialization files is provided in Essential System Administration, Second Edition, by Æleen Frisch (O'Reilly & Associates).
> cd /etc/rc.d > grep ifconfig * rc.inet1:/sbin/ifconfig lo 127.0.0.1 rc.inet1:/sbin/ifconfig eth0 172.16.12.1 broadcast 172.16.12.255 netmask 255.255.255.0
Because network access is important for some of the processes run by the startup files, the ifconfig statements execute near the beginning of the startup procedure. The simplest way to configure a network interface to suit your requirements is to edit the startup files and insert the correct ifconfig statements.
On our Linux system, we edit /etc/rc.d/rc.inet1 and check the two lines necessary to configure the loopback interface and the Ethernet interface. We use the rc.inet1 file because it runs early in network startup procedure and it is the file in which the installation script placed the ifconfig commands. The two lines placed in the file are:
ifconfig lo0 127.0.0.1 ifconfig eth0 172.16.12.1 broadcast 172.16.12.255 netmask 255.255.255.0
Check the startup files to ensure that the interfaces on the host are properly configured at every boot.
|  | |
| 5.5 Summary |  | 6.2 TCP/IP Over a Serial Line |