|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://rtm-cs.sinp.msu.ru/manual/howto/Net-HOWTO.html
Дата изменения: Thu May 4 19:38:28 2000 Дата индексирования: Mon Oct 1 20:46:03 2012 Кодировка: Поисковые слова: lightning |
AF_APPLETALK)
AF_AX25)
AF_IPX)
AF_NETROM)
AF_ROSE)
New versions of this document can always be found first at http://www.linuxports.com/.
Previously the document was called the Net3/4 and Net-3 Howto's. I believe that may not have been obvious enough for certain readers. So, I have renamed it the Networking-HOWTO.
This document has an auto contribute function located at LinuxPorts.Com. (www.linuxports.com/howto/networking/updates.phtml) If you have something that you like like to add to this document you may do so at LinuxPorts.Com page. (www.linuxports.com/howto/networking/updates.phtml)
The original NET-FAQ was written by Matt Welsh and Terry Dawson to answer frequently asked questions about networking for Linux at a time before the Linux Documentation Project had formally started. It covered the very early development versions of the Linux Networking Kernel. The NET-2-HOWTO superceded the NET-FAQ and was one of the original LDP HOWTO documents, it covered what was called version 2 and later version 3 of the Linux kernel Networking software. This document in turn supercedes it and relates only to version 4 of the Linux Networking Kernel or more specifically kernel releases 2.x and 2.2.x.
Previous versions of this document became quite large because of the enormous amount of material that fell within its scope. To help reduce this problem a number of HOWTO's dealing with specific networking topics have been produced. This document will provide pointers to them where relevant and cover those areas not yet covered by other documents.
We are always interested in feedback. Please contact us at: poet@linuxports.com.
Again, if you find anything erroneous or anything you would like to see added, please contact us.
This document is organized top-down. The first sections include informative material and can be skipped if you are not interested; what follows is a generic discussion of networking issues, and you must ensure you understand this before proceeding to more specific parts. The rest, ``technology specific'' information is grouped in three main sections: Ethernet and IP-related information, technologies pertaining to widespread PC hardware and seldom-used technologies.
The suggested path through the document is thus the following:
These sections apply to every, or nearly every, technology described later and so are very important for you to understand. On the other hand, I expect many of the readers to be already confident with this material.
You should know how your network is, or will be, designed and exactly what hardware and technology types you will be implementing.
This section describes basic Ethernet configuration and the various features that Linux offers for IP networks, like firewalling, advanced routing and so on.
The section describes PLIP, PPP, SLIP and ISDN, the widespread technologies used on personal workstations.
If your needs differ from IP and/or common hardware, the final section covers details specific to non-IP protocols and peculiar communication hardware.
You should actually try to configure your network and take careful note of any problems you have.
If you experience problems that this document does not help you to resolve then read the section related to where to get help or where to report bugs.
Networking is fun, enjoy it.
No special convention is used here, but you must be warned about
the way commands are shown. Following the classic Unix documentation,
any command you should type to your shell is prefixed by a
prompt. This howto shows "user%" as the prompt for commands
that do not require superuser privileges, and "root#" as the
prompt for commands that need to run as root. I chose to use
"root#" instead of a plain "#" to prevent confusion
with snapshots from shell scripts, where the hash mark is used to
define comment lines.
When ``Kernel Compile Options'' are shown, they are represented in the format used by menuconfig. They should be understandable even if you (like me) are not used to menuconfig. If you are in doubt about the options' nesting, running the program once can't but help.
There are a number of places where you can find good information about Linux networking.
There are a wealth of Consultants available. A searchable listing can be found at http://www.linuxports.com/
Alan Cox, the current maintainer of the Linux kernel networking code maintains a world wide web page that contains highlights of current and new developments in linux Networking at: www.uk.linux.org.
There is a newsgroup in the Linux news hierarchy dedicated to networking and related matters, it is: comp.os.linux.networking
There is a mailing list to which you can subscribe where you may ask questions relating to Linux networking. To subscribe you should send a mail message:
To: majordomo@vger.rutgers.edu
Subject: anything at all
Message:
subscribe linux-net
Please remember when reporting any problem to include as much relevant detail about the problem as you can. Specifically you should specify the versions of software that you are using, especially the kernel version, the version of tools such as pppd/ or dip and the exact nature of the problem you are experiencing. This means taking note of the exact syntax of any error messages you receive and of any commands that you are issuing.
If you are after some basic tutorial information on tcp/ip networking generally, then I recommend you take a look at the following documents:
this document comes as both a text version and a postscript version.
this document comes as both a text version and a postscript version.
If you are after some more detailed information on tcp/ip networking then I highly recommend:
Internetworking with TCP/IP, Volume 1: principles, protocols and architecture, by Douglas E. Comer, ISBN 0-13-227836-7, Prentice Hall publications, Third Edition, 1995.If you are wanting to learn about how to write network applications in a Unix compatible environment then I also highly recommend:
Unix Network Programming, by W. Richard Stevens, ISBN 0-13-949876-1, Prentice Hall publications, 1990.A second edition of this book is appearing on the bookshelves; the new book is made up of three volumes: check Prenice-Hall's web site to probe further.
You might also try the comp.protocols.tcp-ip newsgroup.
An important source of specific technical information relating to the Internet and the tcp/ip suite of protocols are RFC's. RFC is an acronym for `Request For Comment' and is the standard means of submitting and documenting Internet protocol standards. There are many RFC repositories. Many of these sites are ftp sites and other provide World Wide Web access with an associated search engine that allows you to search the RFC database for particular keywords.
One possible source for RFC's is at Nexor RFC database.
The following subsections you will pretty much need to know and understand before you actually try to configure your network. They are fundamental principles that apply regardless of the exact nature of the network you wish to deploy.
Before you start building or configuring your network you will need some things. The most important of these are:
Please note:
The majority of current distributions come with networking enabled, therefore it may not be required to recompile the kernel. If you are running well known hardware you should be just fine. For example: 3COM NIC, NE2000 NIC, or a Intel NIC. However if you find yourself in the position that you do need to update the kernel, the following information is provided.
Because the kernel you are running now might not yet have support for the network types or cards that you wish to use you will probably need the kernel source so that you can recompile the kernel with the appropriate options.
For users of the major distributions such as Redhat, Caldera, Debian, or Suse this no longer holds true. As long as you stay within the mainstream of hardware there should be no need to recompile your kernel unless there is a very specific feature that you need.
You can always obtain the latest kernel source from ftp.cdrom.com. This is not the official site but they have LOTS of bandwidth and capacity. The official site is kernel.org but please use the above if you can. Please remember that ftp.kernel.org is seriously overloaded. Use a mirror.
Normally the kernel source will be untarred into the
/usr/src/linux directory. For information on how to apply
patches and build the kernel you should read the
Kernel-HOWTO. For information on how
to configure kernel modules you should read the ``Modules
mini-HOWTO''. Also, the README file found in the kernel
sources and the Documentation directory are very informative
for the brave reader.
Unless specifically stated otherwise, I recommend you stick with the standard kernel release (the one with the even number as the second digit in the version number). Development release kernels (the ones with the odd second digit) may have structural or other changes that may cause problems working with the other software on your system. If you are uncertain that you could resolve those sorts of problems in addition to the potential for there being other software errors, then don't use them.
Internet Protocol Addresses are composed of four bytes. The convention is to write addresses in what is called `dotted decimal notation'. In this form each byte is converted to a decimal number (0-255) dropping any leading zero's unless the number is zero and written with each byte separated by a `.' character. By convention each interface of a host or router has an IP address. It is legal for the same IP address to be used on each interface of a single machine in some circumstances but usually each interface will have its own address.
Internet Protocol Networks are contiguous sequences of IP addresses. All addresses within a network have a number of digits within the address in common. The portion of the address that is common amongst all addresses within the network is called the `network portion' of the address. The remaining digits are called the `host portion'. The number of bits that are shared by all addresses within a network is called the netmask and it is role of the netmask to determine which addresses belong to the network it is applied to and which don't. For example, consider the following:
----------------- ---------------
Host Address 192.168.110.23
Network Mask 255.255.255.0
Network Portion 192.168.110.
Host portion .23
----------------- ---------------
Network Address 192.168.110.0
Broadcast Address 192.168.110.255
----------------- ---------------
Any address that is 'bitwise anded' with its netmask will reveal the address of the network it belongs to. The network address is therefore always the lowest numbered address within the range of addresses on the network and always has the host portion of the address coded all zeroes.
The broadcast address is a special address that every host on the network
listens to in addition to its own unique address. This address is the one
that datagrams are sent to if every host on the network is meant to receive
it. Certain types of data like routing information and warning messages
are transmitted to the broadcast address so that every host on the network
can receive it simultaneously. There are two commonly used standards for
what the broadcast address should be. The most widely accepted one is to
use the highest possible address on the network as the broadcast address.
In the example above this would be 192.168.110.255. For some reason
other sites have adopted the convention of using the network address as the
broadcast address. In practice it doesn't matter very much which you use
but you must make sure that every host on the network is configured with the
same broadcast address.
For administrative reasons some time early in the development of the IP protocol some arbitrary groups of addresses were formed into networks and these networks were grouped into what are called classes. These classes provide a number of standard size networks that could be allocated. The ranges allocated are:
--------------------------------------------------------------------------------
| Network | Netmask | Network Addresses |
| Class | | |
--------------------------------------------------------------------------------
| A | 255.0.0.0 | 0.0.0.0 - 127.255.255.255 |
| B | 255.255.0.0 | 128.0.0.0 - 191.255.255.255 |
| C | 255.255.255.0 | 192.0.0.0 - 223.255.255.255 |
|Multicast| 240.0.0.0 | 224.0.0.0 - 239.255.255.255 |
--------------------------------------------------------------------------------
What addresses you should use depends on exactly what it is that you are doing. You may have to use a combination of the following activities to get all the addresses you need:
If you wish to install a linux machine onto an existing IP network then you should contact whoever administers the network and ask them for the following information:
If you are building a private network and you never intend that network to be connected to the Internet then you can choose whatever addresses you like. However, for safety and consistency reasons there have been some IP network addresses that have been reserved specifically for this purpose. These are specified in RFC1597 and are as follows:
-----------------------------------------------------------
| RESERVED PRIVATE NETWORK ALLOCATIONS |
-----------------------------------------------------------
| Network | Netmask | Network Addresses |
| Class | | |
-----------------------------------------------------------
| A | 255.0.0.0 | 10.0.0.0 - 10.255.255.255 |
| B | 255.255.0.0 | 172.16.0.0 - 172.31.255.255 |
| C | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
-----------------------------------------------------------
There are a few different approaches to Linux system boot
procedures. After the kernel boots, it always executes a program
called `init'. The init program then reads its configuration
file called /etc/inittab and commences the boot
process. There are a few different flavours of init around,
although everyone is now converging to the System V (Five) flavor,
developed by Miguel van Smoorenburg.
Despite the fact that the init program is always the same, the setup of system boot is organized in a different way by each distribution.
Usually the /etc/inittab file contains an entry looking something
like:
si::sysinit:/etc/init.d/boot
This line specifies the name of the shell script file that actually manages
the boot sequence. This file is somewhat equivalent to the AUTOEXEC.BAT
file in MS-DOS.
There are usually other scripts that are called by the boot script and often the network is configured within one of many of these.
The following table may be used as a guide for your system:
---------------------------------------------------------------------------
Distrib. | Interface Config/Routing | Server Initialization
---------------------------------------------------------------------------
Debian | /etc/init.d/network | /etc/rc2.d/*
---------------------------------------------------------------------------
Slackware| /etc/rc.d/rc.inet1 | /etc/rc.d/rc.inet2
---------------------------------------------------------------------------
RedHat | /etc/rc.d/init.d/network | /etc/rc.d/rc3.d/*
---------------------------------------------------------------------------
Note that Debian and Red Hat use a whole directory to host scripts
that fire up system services (and usually information does not lie
within these files, for example Red Hat systems store all of system
configuration in files under /etc/sysconfig, whence it is
retrieved by boot scripts). If you want to grasp the details of the
boot process, my suggestion is to check /etc/inittab and the
documentation that accompanies init. Linux Journal is also
going to publish an article about system initialization, and this
document will point to it as soon as it is available on the web.
Most modern distributions include a program that will allow you to configure many of the common sorts of network interfaces. If you have one of these then you should see if it will do what you want before attempting a manual configuration.
-----------------------------------------
Distrib | Network configuration program
-----------------------------------------
RedHat | /usr/bin/netcfg
Slackware | /sbin/netconfig
-----------------------------------------
In many Unix operating systems the network devices have appearances in the /dev directory. This is not so in Linux. In Linux the network devices are created dynamically in software and do not require device files to be present.
In the majority of cases the network device is automatically created by the
device driver while it is initializing and has located your hardware. For
example, the ethernet device driver creates eth[0..n] interfaces
sequentially as it locates your ethernet hardware. The first ethernet card
found becomes eth0, the second eth1 etc.
In some cases though, notably slip and ppp, the network devices are created through the action of some user program. The same sequential device numbering applies, but the devices are not created automatically at boot time. The reason for this is that unlike ethernet devices, the number of active slip or ppp devices may vary during the uptime of the machine. These cases will be covered in more detail in later sections.
When you have all of the programs you need and your address and network information you can configure your network interfaces. When we talk about configuring a network interface we are talking about the process of assigning appropriate addresses to a network device and to setting appropriate values for other configurable parameters of a network device. The program most commonly used to do this is the ifconfig (interface configure) command.
Typically you would use a command similar to the following:
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
In this case I'm configuring an ethernet interface `eth0' with the
IP address `192.168.0.1' and a network mask of `255.255.255.0'.
The `up' that trails the command tells the interface that it should
become active, but can usually be omitted, as it is the default. To
shutdown an interface, you can just call ``ifconfig eth0 down''.
The kernel assumes certain defaults when configuring interfaces. For example,
you may specify the network address and broadcast address for an interface,
but if you don't, as in my example above, then the kernel will make reasonable
guesses as to what they should be based on the netmask you supply and if you
don't supply a netmask then on the network class of the IP address configured.
In my example the kernel would assume that it is a class-C network
being configured on the interface and configure a network address of
`192.168.0.0' and a broadcast address of `192.168.0.255' for the
interface.
There are many other options to the ifconfig command. The most important of these are:
this option activates an interface (and is the default).
this option deactivates an interface.
this option enables or disables use of the address resolution protocol on this interface
this option enables or disables the reception of all hardware multicast packets. Hardware multicast enables groups of hosts to receive packets addressed to special destinations. This may be of importance if you are using applications like desktop videoconferencing but is normally not used.
this parameter allows you to set the MTU of this device.
this parameter allows you to set the network mask of the network this device belongs to.
this parameter only works on certain types of hardware and allows you to set the IRQ of the hardware of this device.
this parameter allows you to enable and set the accepting of datagrams destined to the broadcast address, or to disable reception of these datagrams.
this parameter allows you to set the address of the machine at the remote end of a point to point link such as for slip or ppp.
this parameter allows you to set the hardware address of certain types of network devices. This is not often useful for ethernet, but is useful for other network types such as AX.25.
The name of the interface. This is usually a driver name followed by a unit number, for example eth0 for the first Ethernet interface.
This flag causes the interface to be activated. It is implicitly specified if an address is assigned to the interface.
This flag causes the driver for this interface to be shut down.
Enable or disable the use of the ARP protocol on this interface.
Enable or disable the promiscuous mode of the interface. If selected, all packets on the network will be received by the interface.
Enable or disable all-multicast mode. If selected, all multicast packets on the network will be received by the interface.
This parameter sets the interface metric.
This parameter sets the Maximum Transfer Unit (MTU) of an interface.
Set the remote IP address for a point-to-point link (such as PPP). This keyword is now obsolete; use the pointopoint keyword instead.
Set the IP network mask for