Checking Network Card Speed

Most Ethernet cards sold today are capable of operating at various speeds, such as 10Mbps or 100Mbps. Such devices typically auto-detect and configure themselves for the best possible speed, although a few older boards require driver parameters to set their speed. If you've got such a board and are operating at a lower speed than you believe your hardware should be using, consult your driver's documentation.

Most NICs include a series of light-emitting diodes (LEDs) near their connectors, and one of these LEDs usually denotes the link speed. For most 10/100 NICs, a lit LED indicates that it's connected at 100Mbps. If yours isn't lit and you believe it should be, you should first verify that the rest of your network is operating in 100Mbps mode. If you use hubs to connect your computers, even a single system operating at 10Mbps will bring down the speed of the rest of your components. Tracking down such a problem may be tedious; you may need to turn off or unplug every computer and then turn them on or plug them in one by one until you notice the speed drop. Remember that devices such as print servers qualify as computers and can drag down the transfer speed. Switches don't suffer from this problem. If you have only one 10Mbps device connected to a switch, it will communicate with other computers at 10Mbps, while interactions that don't involve the 10Mbps device will work at 100Mbps. Some "dual-speed" hubs exist. These operate separate 10Mbps and 100Mbps segments with hub-like interaction within each segment but switch-like interactions between them.

Tip Hubs and switches typically include diagnostic LEDs that indicate active connections and often the speed of the connection. These LEDs can be as useful as NIC LEDs in diagnosing problems.

Switches have another advantage over hubs: Switches enable NICs to operate in full-duplex mode, in which both computers involved in a transaction can send data simultaneously, much like a telephone conversation. Hubs use half-duplex mode, in which only one computer can send data at a time, much like using a walkie-talkie. Depending on the nature of your network traffic, full-duplex operation can improve

This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to regist* performance substantially.

Team LIB

Team LIB

^ previous

TCP/IP Basics

A network stack is a set of routines that link applications on one computer to the network hardware, and from there to applications on another computer. Network stacks are built in layers, each of which "packs" or "unpacks" data for transmission to the next layer in the stack. The top layer of the stack consists of applications—both clients (programs that initiate network data transfer, and with which humans usually interact) and servers (programs that respond to network data transfers, and that usually operate semi-independently).

Most networks today use the Transmission Control Protocol/Internet Protocol (TCP/IP) network stack. The Internet is built from TCP/IP, as are most native Unix and Linux networking tools. A few alternative network stacks, such as NetBEUI (used by Windows), IPX/SPX (used by Novell), and AppleTalk (used by Mac OS) also exist. These alternative stacks usually fill limited roles, such as delivering local file- and printer-sharing resources. All major operating systems today support TCP/IP, and many now use it even for local file and printer sharing.

In order to enable inter-computer communications, all network stacks provide some means of addressing. In TCP/IP, this takes the form of an IP address, which is a four-byte number usually expressed in base ten with dots separating each byte, as in 172.30.9.102. An IP address can be broken into two parts:

• A network part, which identifies a unique network

• A machine part, which identifies an individual computer on a network

In practice, the machine part is seldom used alone. This division is accomplished via the network mask (aka the netmask or subnet mask), which takes the form of a series of binary 1 values followed by a series of binary 0 values, totaling 32 bits (4 bytes). Each bit matches with a bit of the IP address. The IP address bits tied to netmask 1 values are part of the network address, and those tied to netmask 0 values are part of the machine address. This arrangement is illustrated in Figure 19.1. Network addresses have traditionally been broken on byte boundaries, yielding network masks that use either 0 or 255 values for each byte, as in 255.255.0.0, but this practice is no longer universal. Network masks can also be expressed as a number of 7 bits following the IP address and a slash, as in 172.30.9.102/16, which indicates an IP address of 172.30.9.102 in conjunction with a netmask of 255.255.0.0.

[¿3 Click To expand

Figure 19.1: TCP/IP addresses are combined with a netmask to isolate the network address.

On a lower level, network hardware also uses addresses. Ethernet NICs, for instance, have 6-byte Media Access Control (MAC) addresses, which are usually expressed as hexadecimal (base 16) values separated by colons or some other punctuation, as in 00:50:BF:19:7E:99. (These addresses are also sometimes called hardware addresses or physical addresses.) The network stack adds the MAC address to outgoing packets, and it discovers the MAC address associated with any given local IP address. MAC addresses are useful only for local networking tasks. For systems off of the remote network, TCP/IP relies on a router—a computer that's connected to more than one network and that directs packets between the networks to which it's connected. The Internet is a very large set of interconnected routers and the computers to which they're connected. You can operate an isolated local network without a router; however, if your computers are connected to the Internet, you must provide them with the IP address of a router (aka a gateway address).

At a higher level than IP addresses, TCP/IP supports hostnames—full alphanumeric names, such as www.sybex.com. These names are broken into parts separated by dots, with the earliest parts being the most specific. TCP/IP supports several mechanisms to tie hostnames to IP addresses, the most important of which is the Domain Name System (DNS). DNS uses a series of servers, each of which is responsible for some part of the Internet. Your local DNS servers, which know about your local computers and how to make queries of other DNS servers to find IP addresses for other systems, are the most important DNS servers from a basic network configuration perspective. No matter how you configure your computers, you must normally give them the IP address for at least one DNS server. Providing two or three addresses creates redundancy, thereby improving reliability.

IPv4 versus IPv6

This chapter emphasizes a particular variety of IP addressing known as IP version 4 or IPv4 for short. As with many computing protocols, of course, changing needs have challenged the limits of IPv4 addressing. One of the most important of these is the

IPv4 address space. A 32-bit address is theoretically capable of handling 2 , or 4,294,967,296 addresses. In practice, the total number of Internet addresses is lower than this because of inefficiencies in how they're doled out. Given the explosive growth of the Internet, IPv4 addressing is reaching its limits in the first years of the 21st century. Other problems, such as increased security threats, contribute to a need to upgrade IPv4.

The successor to IPv4 is IPv6. This version of IP supports a 128-bit address, which

128 38

works out to a theoretical maximum of 2 , or 3.40 x 10 , addresses. This is enough

addresses to assign 2.29 x 10 addresses to each square centimeter of land on the Earth. Switching to IPv6 should therefore be adequate for a while. IPv6 also introduces changes that will help protocol developers to improve security. Unfortunately, the shift is taking quite some time to implement; as I write in early 2003, IPv6 Internet connections are still quite rare. Much of the pressure for a shift has been eased by the implementation of measures designed to minimize the need for new IPv4 addresses, such as widespread adoption of Network Address Translation (NAT), a technique whereby an entire subnetwork can "share" a single external IP address. Nonetheless, IPv6 is still likely to become common in the next few years. Fortunately, Linux already supports IPv6, so if and when you need to make the switch, you'll be able to do so. Configuring a system to use IPv6 addresses, though, is somewhat different than configuring the system to use IPv4 addresses.

Team LIB

Team LiB

DHCP: Promises and Perils

Many networks use DHCP to help simplify network configuration. On such a network, one computer (the DHCP server) delivers IP addresses and related configuration information to other computers (the DHCP clients). Instead of entering half a dozen pieces of information on each client, the clients need only be told to use DHCP. This simplification speeds up client configuration and makes it less likely that errors will creep in and cause problems. Unfortunately, what DHCP promises and what it delivers don't always match. You may find that you need to change your DHCP client's configuration to get it to work on any given network. In extreme cases, you may need to swap out one DHCP client and replace it with another. (Chapter 27 covers the related topic of DHCP server configuration.)

How DHCP Should Work

DHCP relies on broadcasts for its basic functionality. When a computer sends a broadcast, it addresses outgoing packets to all computers or to all computers on a network. For instance, a broadcast might be addressed to 255.255.255.255—a code that means all computers anywhere. Typically, routers don't pass broadcast traffic unless it's directed at a specific subnetwork, which keeps the Internet from being flooded by broadcasts.

When a computer that's configured to be a DHCP client boots or brings up its network interface, the computer sends a broadcast to the DHCP server port. The network's DHCP server computer hears this broadcast and replies to the sender with the basic information the sender needs to configure itself. The DHCP server sends this information to the client by using the client's MAC address, which was embedded in the DHCP broadcast, so the DHCP client doesn't need an IP address to receive the reply. Information that a DHCP server can deliver to its clients includes:

• The client's IP address

• The client's network mask

• The IP address of a router for the local network

• The addresses of one or more DNS servers

• The client's assigned hostname

• The length of the lease on the assigned IP address

• Miscellaneous protocol-specific information

Much of this information is the necessary data for operating on a TCP/IP network, as described earlier, in "TCP/IP Basics." DHCP can provide some protocol-specific information, though, such as the address of a Server Message Block/Common Internet File System (SMB/CIFS) Windows Internet Name Service (WINS) server, which fills much the same role in SMB/CIFS networking as a DNS server fills for most TCP/IP protocols.

The fact that DHCP assigns leases to IP addresses is important. If a computer crashes or shuts down without telling the DHCP server it's going down, the DHCP server must eventually be able to assign the address to another computer; otherwise, the DHCP server might eventually run out of IP addresses, as it might assign multiple addresses, in series, to the same computer. Typical lease times range from a few hours to several days. Ordinarily, a DHCP client contacts the DHCP server to request a lease renewal when the lease time is halfway up. If this contact fails, the client tries again closer to the lease renewal time. Therefore, a computer that's never shut down keeps the same IP address forever, assuming there are no network problems, such as an extended DHCP server outage. DHCP servers can be configured to give computers the same IP addresses repeatedly, based on the clients' MAC addresses or hostnames they pass to the server when they boot. This configuration is optional, though, and must be implemented in the server.

If some basic detail of your network changes, such as the IP address of the router, DHCP makes updating clients simple: You need only change the configuration in the DHCP server, and that change will propagate to all the DHCP clients when they renew their leases. If the change is an important one, such as a router address change, you may want to reduce the lease time on the server sometime prior to the scheduled change, so that clients will receive the updated information soon after you implement the change.

How DHCP Really Works

In theory, DHCP should greatly simplify network configuration for any network that has more than a handful of computers. In practice, of course, DHCP has a few problems:

Client/Server Incompatibility Occasionally, a DHCP client and server simply don't get along well. This type of problem can be extremely frustrating when you're configuring a computer as a DHCP client, because you enter all the data you should enter and it simply doesn't work. Fixing this type of problem for Linux DHCP clients is described in the next two sections, "Tweaking DHCP Clients" and "Changing DHCP Clients."

Dynamic IP Addresses Although computers that run continuously typically use the same IP address for extended periods of time if you use DHCP, this stability isn't guaranteed. A computer's IP address can change, particularly if you shut it down and its lease expires while it's shut down. This characteristic makes DHCP configuration a poor choice for servers unless the DHCP server is configured to deliver the same IP address to the server time after time.

Potential Server Loss If the DHCP server becomes inaccessible, the resulting network problems can be quite severe, because the DHCP clients will drop off the network as their IP addresses expire. You can minimize the potential for such problems by using long lease times. A related problem that's not so easily fixed is the potential for problems should the DHCP server be down or inaccessible when you boot a DHCP client. Depending on the OS and its options, the DHCP client may refuse to bring up its network interface or it may assign itself an IP address—perhaps the last one it used, or possibly an address in a range commonly used for this purpose.

In general, DHCP works well when it's properly configured. If you're setting up a single Linux system or a few Linux systems on an existing network, chances are you have little choice about whether to use DHCP. If your network has a DHCP server and your computer isn't exempted from using it for some reason (say, because it's a server that must have a static IP address), you must use your network's DHCP server. If your network doesn't have a DHCP server, you use a static IP address, as described in the upcoming section, "Using a Static IP Address."

Tweaking DHCP Clients

Most Linux distributions ship with one or more of four DHCP clients: pump, dhclient, dhcpxd, or dhcpcd (don't confuse either of the last two with dhcpd, the most common Linux DHCP server). Table 19.1 summarizes which clients come with which distributions, along with information about the startup scripts and configuration files that call and configure these clients. This information is critical if you want to modify a DHCP client configuration using anything except your distribution's GUI configuration tools.

Note Network configuration files sometimes bear the name of the network interface, such as ifcfg-ethO for the ethO interface. If you're using a non-Ethernet interface or if you have more than one NIC, these names will be different.

If you configure your computer to use DHCP by using your distribution's standard tools, chances are the system worked when you started it (assuming your network has an appropriate DHCP server, of course). If it didn't work, you must edit your configuration in some way. You can take any of four approaches to this task:

Use Your Distribution's Configuration Tools The most straightforward approach is to attempt to use your distribution's GUI configuration tools to fix the problem. Many tools provide some way to enter common details that you may need to provide to your DHCP client, such as a system name. (Some networks require DHCP clients to announce themselves by name.) Unfortunately, some GUI tools are extremely limited in the DHCP client options they enable you to adjust, so you may need to take another approach.

Edit the Extra Configuration Files In most distributions, the files listed under the Extra Configuration Files column of Table 19.1 control DHCP client options. Peruse these files looking for options you can adjust, such as the hostname the DHCP client presents to the DHCP server.

Table 19.1: DHCP Client Configuration Information

DHCP

DHCP

Clients

DHCP Client Startup Script

Extra Configuration Files

Debian

GNU/Linux

3.0

dhclient

pump

/sbin/ifup-

/etc/n etwo rk/i nte rfaces, /etc/dhclient.conf

Mandrake Linux 9.1

dhclient

dhcpcd, dhcpxd, pump

/sb in/if up

/etc/sysco n fig/n etwo rk,

/etc/sysconfig/network-scripts/ifcfg-ethO,

/etc/dhclient-ethO.conf

Red Hat Linux 9.0

dhclient

none

/sb in/if up

/etc/sysco n fig/n etwo rk,

/etc/sysconfig/

network-scripts/ifcfg-ethO

Slackware Linux 9.0

dhcpcd

none

/etc/rc.d/rc.inet1

none

SuSE Linux 8.1

dhcpcd

dhclient

/sbin/ifup-dhcp

/etc/sysco n fig/n etwo rk/d hep, /etc/sysco n fig/n etwo rk/ ifcfg-ethO

- Binary executable, not a script

Edit the DHCP Startup Script If you can't figure out what to change in the configuration files or if making these changes is ineffective, you can try editing the startup script. Consult the man page for your DHCP client to learn about options you can use, then modify the startup script to pass those options directly. Alternatively, examining the startup script may provide you with the information you need to edit the configuration file to get the job done. Unfortunately, Debian's

/sbin/ifup "script" is really a compiled binary program, so this approach is impractical with Debian unless you want to track down, edit, and recompile the program's source code or replace /sbin/ifup with your own script.

Bypass Normal Network Startup Tools Finally, if all else fails, you can try bypassing the normal startup script process, as described in Chapter 9. For instance, you could call your DHCP client from a local startup script.

Changing DHCP Clients

Sometimes tweaking a DHCP client configuration just isn't enough. A DHCP server configuration may be fussy enough to just plain not work with a client. As a general rule, pump is the most troublesome client. Fortunately, few modern distributions use pump (none of the five summarized in Table 19.1 use it by default). Some older distributions used pump, though, and you might have installed it by accident. It's also possible that your DHCP server doesn't get along with dhclient ordhcpcd. If that's the case, you must change your DHCP client.

Most distributions automatically detect DHCP clients and run them, no matter which client you have installed. Table 19.1 lists the clients that ship with each distribution. The DHCP startup script should recognize all of these clients and, in some cases, more. Therefore, the simplest way to reconfigure your DHCP client is to use your package system, as described in Chapter 11, "Managing Packages," to remove the DHCP client your system is configured to use and to install another one. When you reboot, the system should try to use the new DHCP client. To use the new DHCP client without rebooting, try using your distribution's SysV startup scripts. For instance, on Mandrake, you might type:

# /etc/rc.d/init.d/network stop

# /etc/rc.d/init.d/network start

The network, including the new DHCP client, should be up again a few seconds after you type the second command. Try using ps to verify that the new DHCP client is running, as in ps ax | grep dhcpcd to search for dhcpcd; and type ifconfig ethO to view the new network configuration and verify that your system has an IP address. (Both of these commands can be issued from non-root accounts.)

Team LiB

^ previous next ^

0 0

Post a comment