Table of Contents for
Linux Network Administrator's Guide, Second Edition

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Linux Network Administrator's Guide, Second Edition by Terry Dawson Published by O'Reilly Media, Inc., 2000
  1. Cover
  2. Linux Network Administrator’s Guide, 2nd Edition
  3. Preface
  4. Sources of Information
  5. File System Standards
  6. Standard Linux Base
  7. About This Book
  8. The Official Printed Version
  9. Overview
  10. Conventions Used in This Book
  11. Submitting Changes
  12. Acknowledgments
  13. 1. Introduction to Networking
  14. TCP/IP Networks
  15. UUCP Networks
  16. Linux Networking
  17. Maintaining Your System
  18. 2. Issues of TCP/IP Networking
  19. IP Addresses
  20. Address Resolution
  21. IP Routing
  22. The Internet Control Message Protocol
  23. Resolving Host Names
  24. 3. Configuring the Networking Hardware
  25. A Tour of Linux Network Devices
  26. Ethernet Installation
  27. The PLIP Driver
  28. The PPP and SLIP Drivers
  29. Other Network Types
  30. 4. Configuring the Serial Hardware
  31. Introduction to Serial Devices
  32. Accessing Serial Devices
  33. Serial Hardware
  34. Using the Configuration Utilities
  35. Serial Devices and the login: Prompt
  36. 5. Configuring TCP/IP Networking
  37. Installing the Binaries
  38. Setting the Hostname
  39. Assigning IP Addresses
  40. Creating Subnets
  41. Writing hosts and networks Files
  42. Interface Configuration for IP
  43. All About ifconfig
  44. The netstat Command
  45. Checking the ARP Tables
  46. 6. Name Service and Resolver Configuration
  47. How DNS Works
  48. Running named
  49. 7. Serial Line IP
  50. SLIP Operation
  51. Dealing with Private IP Networks
  52. Using dip
  53. Running in Server Mode
  54. 8. The Point-to-Point Protocol
  55. Running pppd
  56. Using Options Files
  57. Using chat to Automate Dialing
  58. IP Configuration Options
  59. Link Control Options
  60. General Security Considerations
  61. Authentication with PPP
  62. Debugging Your PPP Setup
  63. More Advanced PPP Configurations
  64. 9. TCP/IP Firewall
  65. What Is a Firewall?
  66. What Is IP Filtering?
  67. Setting Up Linux for Firewalling
  68. Three Ways We Can Do Filtering
  69. Original IP Firewall (2.0 Kernels)
  70. IP Firewall Chains (2.2 Kernels)
  71. Netfilter and IP Tables (2.4 Kernels)
  72. TOS Bit Manipulation
  73. Testing a Firewall Configuration
  74. A Sample Firewall Configuration
  75. 10. IP Accounting
  76. Configuring IP Accounting
  77. Using IP Accounting Results
  78. Resetting the Counters
  79. Flushing the Ruleset
  80. Passive Collection of Accounting Data
  81. 11. IP Masquerade and Network Address Translation
  82. Configuring the Kernel for IP Masquerade
  83. Configuring IP Masquerade
  84. Handling Name Server Lookups
  85. More About Network Address Translation
  86. 12. Important Network Features
  87. The tcpd Access Control Facility
  88. The Services and Protocols Files
  89. Remote Procedure Call
  90. Configuring Remote Login and Execution
  91. 13. The Network Information System
  92. NIS Versus NIS+
  93. The Client Side of NIS
  94. Running an NIS Server
  95. NIS Server Security
  96. Setting Up an NIS Client with GNU libc
  97. Choosing the Right Maps
  98. Using the passwd and group Maps
  99. Using NIS with Shadow Support
  100. 14. The Network File System
  101. Mounting an NFS Volume
  102. The NFS Daemons
  103. The exports File
  104. Kernel-Based NFSv2 Server Support
  105. Kernel-Based NFSv3 Server Support
  106. 15. IPX and the NCP Filesystem
  107. IPX and Linux
  108. Configuring the Kernel for IPX and NCPFS
  109. Configuring IPX Interfaces
  110. Configuring an IPX Router
  111. Mounting a Remote NetWare Volume
  112. Exploring Some of the Other IPX Tools
  113. Printing to a NetWare Print Queue
  114. NetWare Server Emulation
  115. 16. Managing Taylor UUCP
  116. UUCP Configuration Files
  117. Controlling Access to UUCP Features
  118. Setting Up Your System for Dialing In
  119. UUCP Low-Level Protocols
  120. Troubleshooting
  121. Log Files and Debugging
  122. 17. Electronic Mail
  123. How Is Mail Delivered?
  124. Email Addresses
  125. How Does Mail Routing Work?
  126. Configuring elm
  127. 18. Sendmail
  128. Installing sendmail
  129. Overview of Configuration Files
  130. The sendmail.cf and sendmail.mc Files
  131. Generating the sendmail.cf File
  132. Interpreting and Writing Rewrite Rules
  133. Configuring sendmail Options
  134. Some Useful sendmail Configurations
  135. Testing Your Configuration
  136. Running sendmail
  137. Tips and Tricks
  138. 19. Getting Exim Up and Running
  139. If Your Mail Doesn’t Get Through
  140. Compiling Exim
  141. Mail Delivery Modes
  142. Miscellaneous config Options
  143. Message Routing and Delivery
  144. Protecting Against Mail Spam
  145. UUCP Setup
  146. 20. Netnews
  147. What Is Usenet, Anyway?
  148. How Does Usenet Handle News?
  149. 21. C News
  150. Installation
  151. The sys File
  152. The active File
  153. Article Batching
  154. Expiring News
  155. Miscellaneous Files
  156. Control Messages
  157. C News in an NFS Environment
  158. Maintenance Tools and Tasks
  159. 22. NNTP and the nntpd Daemon
  160. Installing the NNTP Server
  161. Restricting NNTP Access
  162. NNTP Authorization
  163. nntpd Interaction with C News
  164. 23. Internet News
  165. Newsreaders and INN
  166. Installing INN
  167. Configuring INN: the Basic Setup
  168. INN Configuration Files
  169. Running INN
  170. Managing INN: The ctlinnd Command
  171. 24. Newsreader Configuration
  172. trn Configuration
  173. nn Configuration
  174. A. Example Network: The Virtual Brewery
  175. B. Useful Cable Configurations
  176. A Serial NULL Modem Cable
  177. C. Linux Network Administrator’s Guide, Second Edition Copyright Information
  178. 1. Applicability and Definitions
  179. 2. Verbatim Copying
  180. 3. Copying in Quantity
  181. 4. Modifications
  182. 5. Combining Documents
  183. 6. Collections of Documents
  184. 7. Aggregation with Independent Works
  185. 8. Translation
  186. 9. Termination
  187. 10. Future Revisions of this License
  188. D. SAGE: The System Administrators Guild
  189. Index
  190. Colophon

IP Routing

We now take up the question of finding the host that datagrams go to based on the IP address. Different parts of the address are handled in different ways; it is your job to set up the files that indicate how to treat each part.

IP Networks

When you write a letter to someone, you usually put a complete address on the envelope specifying the country, state, and Zip Code. After you put it in the mailbox, the post office will deliver it to its destination: it will be sent to the country indicated, where the national service will dispatch it to the proper state and region. The advantage of this hierarchical scheme is obvious: wherever you post the letter, the local postmaster knows roughly which direction to forward the letter, but the postmaster doesn’t care which way the letter will travel once it reaches its country of destination.

IP networks are structured similarly. The whole Internet consists of a number of proper networks, called autonomous systems. Each system performs routing between its member hosts internally so that the task of delivering a datagram is reduced to finding a path to the destination host’s network. As soon as the datagram is handed to any host on that particular network, further processing is done exclusively by the network itself.

Subnetworks

This structure is reflected by splitting IP addresses into a host and network part, as explained previously. By default, the destination network is derived from the network part of the IP address. Thus, hosts with identical IP network numbers should be found within the same network.[15]

It makes sense to offer a similar scheme inside the network, too, since it may consist of a collection of hundreds of smaller networks, with the smallest units being physical networks like Ethernets. Therefore, IP allows you to subdivide an IP network into several subnets.

A subnet takes responsibility for delivering datagrams to a certain range of IP addresses. It is an extension of the concept of splitting bit fields, as in the A, B, and C classes. However, the network part is now extended to include some bits from the host part. The number of bits that are interpreted as the subnet number is given by the so-called subnet mask, or netmask. This is a 32-bit number too, which specifies the bit mask for the network part of the IP address.

The campus network of Groucho Marx University is an example of such a network. It has a class B network number of 149.76.0.0, and its netmask is therefore 255.255.0.0.

Internally, GMU’s campus network consists of several smaller networks, such various departments’ LANs. So the range of IP addresses is broken up into 254 subnets, 149.76.1.0 through 149.76.254.0. For example, the department of Theoretical Physics has been assigned 149.76.12.0. The campus backbone is a network in its own right, and is given 149.76.1.0. These subnets share the same IP network number, while the third octet is used to distinguish between them. They will thus use a subnet mask of 255.255.255.0.

Figure 2.1 shows how 149.76.12.4, the address of quark, is interpreted differently when the address is taken as an ordinary class B network and when used with subnetting.

Subnetting a class B network

Figure 2-1. Subnetting a class B network

It is worth noting that subnetting (the technique of generating subnets) is only an internal division of the network. Subnets are generated by the network owner (or the administrators). Frequently, subnets are created to reflect existing boundaries, be they physical (between two Ethernets), administrative (between two departments), or geographical (between two locations), and authority over each subnet is delegated to some contact person. However, this structure affects only the network’s internal behavior, and is completely invisible to the outside world.

Gateways

Subnetting is not only a benefit to the organization; it is frequently a natural consequence of hardware boundaries. The viewpoint of a host on a given physical network, such as an Ethernet, is a very limited one: it can only talk to the host of the network it is on. All other hosts can be accessed only through special-purpose machines called gateways. A gateway is a host that is connected to two or more physical networks simultaneously and is configured to switch packets between them.

Figure 2.2 shows part of the network topology at Groucho Marx University (GMU). Hosts that are on two subnets at the same time are shown with both addresses.

A part of the net topology at Groucho Marx University

Figure 2-2. A part of the net topology at Groucho Marx University

Different physical networks have to belong to different IP networks for IP to be able to recognize if a host is on a local network. For example, the network number 149.76.4.0 is reserved for hosts on the mathematics LAN. When sending a datagram to quark, the network software on erdos immediately sees from the IP address 149.76.12.4 that the destination host is on a different physical network, and therefore can be reached only through a gateway (sophus by default).

sophus itself is connected to two distinct subnets: the Mathematics department and the campus backbone. It accesses each through a different interface, eth0 and fddi0, respectively. Now, what IP address do we assign it? Should we give it one on subnet 149.76.1.0, or on 149.76.4.0?

The answer is: “both.” sophus has been assigned the address 149.76.1.1 for use on the 149.76.1.0 network and address 149.76.4.1 for use on the 149.76.4.0 network. A gateway must be assigned one IP address for each network it belongs to. These addresses—along with the corresponding netmask—are tied to the interface through which the subnet is accessed. Thus, the interface and address mapping for sophus would look like this:

InterfaceAddressNetmask
eth0 149.76.4.1255.255.255.0
fddi0 149.76.1.1255.255.255.0
lo 127.0.0.1255.0.0.0

The last entry describes the loopback interface lo, which we talked about earlier.

Generally, you can ignore the subtle difference between attaching an address to a host or its interface. For hosts that are on one network only, like erdos, you would generally refer to the host as having this-and-that IP address, although strictly speaking, it’s the Ethernet interface that has this IP address. The distinction is really important only when you refer to a gateway.

The Routing Table

We now focus our attention on how IP chooses a gateway to use to deliver a datagram to a remote network.

We have seen that erdos, when given a datagram for quark, checks the destination address and finds that it is not on the local network. erdos therefore sends the datagram to the default gateway sophus, which is now faced with the same task. sophus recognizes that quark is not on any of the networks it is connected to directly, so it has to find yet another gateway to forward it through. The correct choice would be niels, the gateway to the Physics department. sophus thus needs information to associate a destination network with a suitable gateway.

IP uses a table for this task that associates networks with the gateways by which they may be reached. A catch-all entry (the default route) must generally be supplied too; this is the gateway associated with network 0.0.0.0. All destination addresses match this route, since none of the 32 bits are required to match, and therefore packets to an unknown network are sent through the default route. On sophus, the table might look like this:

NetworkNetmaskGatewayInterface
149.76.1.0255.255.255.0- fddi0
149.76.2.0255.255.255.0149.76.1.2 fddi0
149.76.3.0255.255.255.0149.76.1.3 fddi0
149.76.4.0255.255.255.0- eth0
149.76.5.0255.255.255.0149.76.1.5 fddi0
............
0.0.0.00.0.0.0149.76.1.2 fddi0

If you need to use a route to a network that sophus is directly connected to, you don’t need a gateway; the gateway column here contains a hyphen.

The process for identifying whether a particular destination address matches a route is a mathematical operation. The process is quite simple, but it requires an understanding of binary arithmetic and logic: A route matches a destination if the network address logically ANDed with the netmask precisely equals the destination address logically ANDed with the netmask.

Translation: a route matches if the number of bits of the network address specified by the netmask (starting from the left-most bit, the high order bit of byte one of the address) match that same number of bits in the destination address.

When the IP implementation is searching for the best route to a destination, it may find a number of routing entries that match the target address. For example, we know that the default route matches every destination, but datagrams destined for locally attached networks will match their local route, too. How does IP know which route to use? It is here that the netmask plays an important role. While both routes match the destination, one of the routes has a larger netmask than the other. We previously mentioned that the netmask was used to break up our address space into smaller networks. The larger a netmask is, the more specifically a target address is matched; when routing datagrams, we should always choose the route that has the largest netmask. The default route has a netmask of zero bits, and in the configuration presented above, the locally attached networks have a 24-bit netmask. If a datagram matches a locally attached network, it will be routed to the appropriate device in preference to following the default route because the local network route matches with a greater number of bits. The only datagrams that will be routed via the default route are those that don’t match any other route.

You can build routing tables by a variety of means. For small LANs, it is usually most efficient to construct them by hand and feed them to IP using the route command at boot time (see Chapter 5). For larger networks, they are built and adjusted at runtime by routing daemons; these daemons run on central hosts of the network and exchange routing information to compute “optimal” routes between the member networks.

Depending on the size of the network, you’ll need to use different routing protocols. For routing inside autonomous systems (such as the Groucho Marx campus), the internal routing protocols are used. The most prominent one of these is the Routing Information Protocol (RIP), which is implemented by the BSD routed daemon. For routing between autonomous systems, external routing protocols like External Gateway Protocol (EGP) or Border Gateway Protocol (BGP) have to be used; these protocols, including RIP, have been implemented in the University of Cornell’s gated daemon.

Metric Values

We depend on dynamic routing to choose the best route to a destination host or network based on the number of hops. Hops are the gateways a datagram has to pass before reaching a host or network. The shorter a route is, the better RIP rates it. Very long routes with 16 or more hops are regarded as unusable and are discarded.

RIP manages routing information internal to your local network, but you have to run gated on all hosts. At boot time, gated checks for all active network interfaces. If there is more than one active interface (not counting the loopback interface), it assumes the host is switching packets between several networks and will actively exchange and broadcast routing information. Otherwise, it will only passively receive RIP updates and update the local routing table.

When broadcasting information from the local routing table, gated computes the length of the route from the so-called metric value associated with the routing table entry. This metric value is set by the system administrator when configuring the route, and should reflect the actual route cost.[16] Therefore, the metric of a route to a subnet that the host is directly connected to should always be zero, while a route going through two gateways should have a metric of two. You don’t have to bother with metrics if you don’t use RIP or gated.



[15] Autonomous systems are slightly more general. They may comprise more than one IP network.

[16] The cost of a route can be thought of, in a simple case, as the number of hops required to reach the destination. Proper calculation of route costs can be a fine art in complex network designs.