pkg://Linux-HOWTOs.tar.gz:1682658/NET-3-HOWTO
downloads
Linux NET-3-HOWTO, Linux Networking.
Terry Dawson, VK2KTJ, terry@perf.no.itg.telstra.com.au
v1.2, 20 August 1997
The Linux Operating System boasts kernel based networking support
written almost entirely from scratch. The performance of the tcp/ip
implementation in recent kernels makes it a worthy alternative to even
the best of its peers. This document aims to describe how to install
and configure the Linux networking software and associated tools.
1. Changes from the previous version
Additions:
Reference to PLIP-mini-HOWTO - thanks Claes
IP NAT - Network Address Translation
Corrections/Updates:
Many corrections from Alessandro Rubini - thanks!
Updated Larry Stefani's email address - thanks Larry
Corrected ftp.linux.uk.org nettools location - thanks Ron
Corrected incorrect route command - thanks John
More broken route commands! - thanks Jean-Pierre
IPv6 addresses are 16 bytes not 32, oops - thanks Erez
ToDo:
Add traffic shaper
Describe new routing algorithm
Add IPv6 kernel compile options
Describe /proc/sys/net/* entries.
WanRouter device
2. Introduction.
The original NET-FAQ was written by Matt Welsh and I 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 3 of the Linux
Networking Kernel.
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.
2.1. Feedback
I always appreciate feedback and especially value contributions.
Please direct any feedback or contributions to me by email
<mailto:terry@perf.no.itg.telstra.com.au>.
3. How to use this HOWTO document (NET-3-HOWTO-HOWTO ?).
The format of this document is differs from earlier versions. I've now
regrouped the sections so that there is informative material at the
beginning which you can skip if you are not interested, generic
material next which you must ensure you understand before proceeding
to the technology specific sections in the rest of the document.
Read the generic sections
These sections apply to every, or nearly every, technology
described later and so are very important for you to understand.
Consider your network
You should know how your network is, or will be, designed and
exactly what hardware and technology types you will be
implementing.
Read the technology specific sections related to your requirements
When you know what you want you can address each component in
turn. These sections cover only details specific to a particular
technology.
Do the configuration work
You should actually try to configure your network and take
careful note of any problems you have.
Look for further help if needed
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.
Have fun!
Networking is fun, enjoy it.
4. General Information about Linux Networking.
4.1. A brief history of Linux Networking Kernel Development.
Developing a brand new kernel implementation of the tcp/ip protocol
stack that would perform as well as existing implementations was not
an easy task. The decision not to port one of the existing
implementations was made at a time when there was some uncertainty as
to whether the existing implementations may become encumbered by
restrictive copyrights because of the court case put by U.S.L. and
when there was a lot of fresh enthusiasm for doing it differently and
perhaps even better than had already been done.
The original volunteer to lead development of the kernel network code
was Ross Biro <biro@yggdrasil.com>. Ross produced a simple and
incomplete but mostly usable implementation set of routines that were
complemented by an ethernet driver for the WD-8003 network interface
card. This was enough to get many people testing and experimenting
with the software and some people even managed to connect machines in
this configuration to live internet connections. The pressure within
the Linux community driving development for networking support was
building and eventually the cost of a combination of some unfair
pressure applied to Ross and his own personal commitments outweighed
the benefit he was deriving and he stepped down as lead developer.
Ross's efforts in getting the project started and accepting the
responsibility for actually producing something useful in such
controversial circumstances were what catalysed all future work and
were therefore an essential component of the success of the current
product.
Orest Zborowski <obz@Kodak.COM> produced the original BSD socket
programming interface for the Linux kernel. This was a big step
forward as it allowed many of the existing network applications to be
ported to linux without serious modification.
Somewhere about this time Laurence Culhane <loz@holmes.demon.co.uk>
developed the first drivers for Linux to support the SLIP protocol.
These enabled many people who did not have access to Ethernet
networking to experiment with the new networking software. Again, some
people took this driver and pressed it into service to connect them to
the Internet. This gave many more people a taste of the possibilities
that could be realised if Linux had full networking support and grew
the number of users actively using and experimenting with the
networking software that existed.
One of the people that had also been actively working on the task of
building networking support was Fred van Kempen
<waltje@uwalt.nl.mugnet.org>. After a period of some uncertainty
following Ross's resignation from the lead developer position Fred
offered his time and effort and accepted the role essentially
unopposed. Fred had some ambitious plans for the direction that he
wanted to take the Linux networking software and he set about
progressing in those directions. Fred produced a series of networking
code called the `NET-2' kernel code (the `NET' code being Ross's)
which many people were able to use pretty much usefully. Fred formally
put a number of innovations on the development agenda, such as the
dynamic device interface, Amateur Radio AX.25 protocol support and a
more modularly designed networking implementation. Fred's NET-2 code
was used by a fairly large number of enthusiasts, the number
increasing all the time as word spread that the software was working.
The networking software at this time was still a large number of
patches to the standard release of kernel code and was not included in
the normal release. The NET-FAQ and subsequent NET-2-HOWTO's
described the then fairly complex procedure to get it all working.
Fred's focus was on developing innovations to the standard network
implementations and this was taking time. The community of users was
growing impatient for something that worked reliably and satisfied the
80% of users and, as with Ross, the pressure on Fred as lead developer
rose.
Alan Cox <iialan@www.uk.linux.org> proposed a solution to the problem
designed to resolve the situation. He proposed that he would take
Fred's NET-2 code and debug it, making it reliable and stable so that
it would satisfy the impatient user base while relieving that pressure
from Fred allowing him to continue his work. Alan set about doing
this, with some good success and his first version of Linux networking
code was called `Net-2D(ebugged)'. The code worked reliably in many
typical configurations and the user base was happy. Alan clearly had
ideas and skills of his own to contribute to the project and many
discussions relating to the direction the NET-2 code was heading
ensued. There developed two distinct schools within the Linux
networking community, one that had the philosophy of `make it work
first, then make it better' and the other of `make it better first'.
Linus ultimately arbitrated and offered his support to Alan's
development efforts and included Alan's code in the standard kernel
source distribution. This placed Fred in a difficult position. Any
continued development would lack the large user base actively using
and testing the code and this would mean progress would be slow and
difficult. Fred continued to work for a short time and eventually
stood down and Alan came to be the new leader of the Linux networking
kernel development effort.
Donald Becker <becker@cesdis.gsfc.nasa.gov> soon revealed his talents
in the low level aspects of networking and produced a huge range of
ethernet drivers, nearly all of those included in the current kernels
were developed by Donald. There have been other people that have made
significant contributions, but Donald's work is prolific and so
warrants special mention.
Alan continued refining the NET-2-Debugged code for some time while
working on progressing some of the matters that remained unaddressed
on the `TODO' list. By the time the Linux 1.3.* kernel source had
grown its teeth the kernel networking code had migrated to the NET-3
release on which current versions are based. Alan worked on many
different aspects of the networking code and with the assistance of a
range of other talented people from the Linux networking community
grew the code in all sorts of directions. Alan produced dynamic
network devices and the first standard AX.25 and IPX implementations.
Alan has continued tinkering with the code, slowly restructuring and
enhancing it to the state it is in today.
PPP support was added by Michael Callahan <callahan@maths.ox.ac.uk>
and Al Longyear <longyear@netcom.com> this too was critical to
increasing the number of people actively using linux for networking.
Jonathon Naylor <jsn@cs.nott.ac.uk> has contributed by significantly
enhancing Alan's AX.25 code, adding NetRom and Rose protocol support.
The AX.25/NetRom/Rose support itself is quite significant, because no
other operating system can boast standard native support for these
protocols beside Linux.
There have of course been hundreds of other people who have made
significant contribution to the development of the Linux networking
software. Some of these you will encounter later in the technology
specific sections, other people have contributed modules, drivers,
bug-fixes, suggestions, test reports and moral support. In all cases
each can claim to have played a part and offered what they could. The
Linux kernel networking code is an excellent example of the results
that can be obtained from the Linux style of anarchic development, if
it hasn't yet surprised you, it is bound to soon enough, the
development hasn't stopped.
4.2. Where to get other information about Linux Networking.
There are a number of places where you can find good information about
Linux networking.
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
<http://www.uk.linux.org/NetNews.html>.
Another good place is a book written by Olaf Kirch entitled the
Network Administrators Guide. It is a work of the Linux
Documentatation Project <http://sunsite.unc.edu/LDP/> and you can read
it interactively at Network Administrators Guide HTML version
<http://sunsite.unc.edu/LDP/LDP/nag/nag.html> or you can obtain it in
various formats by ftp from the sunsite.unc.edu LDP ftp archive
<ftp://sunsite.unc.edu/pub/Linux/docs/LDP/network-guide/>. Olaf's book
is quite comprehensive and provides a good high level overview of
network configuration under linux.
There is a newsgroup in the Linux news heirarchy dedicated to
networking and related matters, it is: comp.os.linux.networking
<news: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
On the various IRC networks there are often #linux channels on which
people will be able to answer questions on linux networking.
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.
4.3. Where to get some non-linux-specific network information.
If you are after some basic tutorial information on tcp/ip networking
generally, then I recommend you take a look at the following
documents:
tcp/ip introduction
this document comes as both a text version
<ftp://athos.rutgers.edu/runet/tcp-ip-intro.doc> and a
postscript version <ftp://athos.rutgers.edu/runet/tcp-ip-
intro.ps>.
tcp/ip administration
this document comes as both a text version
<ftp://athos.rutgers.edu/runet/tcp-ip-admin.doc> and a
postscript version <ftp://athos.rutgers.edu/runet/tcp-ip-
admin.ps>.
If you are after some more detailed information on tcp/ip networking
then I highly recommend:
"Internetworking with TCP/IP"
by Douglas E. Comer
ISBN 0-13-474321-0
Prentice Hall publications.
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.
You might also try the comp.protocols.tcp-ip <news: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
<http://pubweb.nexor.co.uk/public/rfc/index/rfc.html>.
5. Generic Network Configuration Information.
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.
5.1. What do I need to start ?
Before you start building or configuring your network you will need
some things. The most important of these are:
5.1.1. Current Kernel source.
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.
You can always obtain the latest kernel source from: ftp.funet.fi
<ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/v2.0>.
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 <Kernel-HOWTO.html>. For
information on how to configure kernel modules you should read the
Module-HOWTO <Module-HOWTO.html>.
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.
5.1.2. Current Network tools.
The network tools are the programs that you use to configure linux
network devices. These tools allow you to assign addresses to devices
and configure routes for example.
Most modern linux distributions are supplied with the network tools,
so if you have installed from a distribution and haven't yet installed
the network tools then you should do so.
If you haven't installed from a distribution then you will need to
source and compile the tools yourself. This isn't difficult.
The network tools are now maintained by Bernd Eckenfels and are
available at: ftp.inka.de
<ftp://ftp.inka.de/pub/comp/Linux/networking/NetTools/> and are
mirrored at: ftp.uk.linux.org
<ftp://ftp.uk.linux.org/pub/linux/Networking/base/>.
Be sure to choose the version that is most appopriate for the kernel
you wish to use and follow the instructions in the package to install.
To install and configure the version current at the time of the
writing you need do the following:
#
# cd /usr/src
# tar xvfz net-tools-1.33.tar.gz
# cd net-tools-1.33
# make config
# make
# make install
#
Additionally, if you intend configuring a firewall or using the IP
masquerade feature you will require the ipfwadm command. The latest
version of it may be obtained from: ftp.xos.nl
<ftp:/ftp.xos.nl/pub/linux/ipfwadm>. Again there are a number of
versions available. Be sure to pick the version that most closely
matches your kernel.
To install and configure the version current at the time of the
writing you need do the following:
#
# cd /usr/src
# tar xvfz ipfwadm-2.3.0.tar.gz
# cd ipfwadm-2.3.0
# make
# make install
#
5.1.3. Network Application Programs.
The network application programs are programs such as telnet and ftp
and their respective server programs. David Holland
<dholland@hcs.harvard.edu> now manages a distribution of the most
common of these. You may obtain it from: ftp.uk.linux.org
<ftp://ftp.uk.linux.org/pub/linux/Networking/base>.
To install and configure the version current at the time of the
writing you need do the following:
#
# cd /usr/src
# tar xvfz /pub/net/NetKit-B-0.08.tar.gz
# cd NetKit-B-0.08
# more README
# vi MCONFIG
# make
# make install
#
5.1.4. Addresses.
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 seperated 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 thhat 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:
Installing a linux machine on an existing IP network
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:
· Host IP Address
· IP network address
· IP broadcast address
· IP netmask
· Router address
· Domain Name Server Address
You should then configure your linux network device with those
details. You can not make them up and expect your configuration
to work.
Building a brand new network that will never connect to the Inter
net
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 |
-----------------------------------------------------------
You should first decide how large you want your network to be and
then choose as many of the addresses as you require.
5.2. Where should I put the configuration commands ?
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 and it is this variation that is the largest cause of variation
between distributions or machines.
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 Initialisation
-------------------------------------------------------------------------------
Debian |/etc/init.d/network |/etc/init.d/netbase
| |/etc/init.d/netstd_init
| |/etc/init.d/netstd_nfs
| |/etc/init.d/netstd_misc
-------------------------------------------------------------------------------
Slackware|/etc/rc.d/rc.inet1 |/etc/rc.d/rc.inet2
-------------------------------------------------------------------------------
RedHat |/etc/sysconfig/network-scripts/ifup-<ifname>|/etc/rc.d/init.d/network
-------------------------------------------------------------------------------
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 | /sbin/netcfg
Slackware | /sbin/netconfig
-----------------------------------------
5.3. Creating your network interfaces.
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 thus do not require
device files to be present.
In the majority of cases the network devices is automatically created
by the device driver while it is initialising 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.
5.4. Configuring a network interface.
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 paramaters 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:
# 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.
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:
up this option activates an interface.
down
this option deactivates an interface.
[-]arp
this option enables or disables use of the address resolution
protocol on this interface
[-]allmulti
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.
mtu N
this parameter allows you to set the MTU of this device.
netmask addr
this parameter allows you to set the network mask of the network
this device belongs to.
irq addr
this parameter only works on certain types of hardware and
allows you to set the IRQ of the hardware of this device.
[-]broadcast [addr]
this parameter allows you to enable and set the accepting of
datagrams destined to the broadcast address, or to disable
reception of these datagrams.
[-]pointopoint [addr]
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.
hw <type> <addr>
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.
You may use the ifconfig command on any network interface. Some user
programs such as pppd and dip automatically configure the network
devices as they create them, so manual use of ifconfig is unnecessary.
5.5. Configuring your Name Resolver.
The `Name Resolver' is a part of the linux standard library. Its prime
function is to provide a service to convert human-friendly hostnames
like `ftp.funet.fi' into machine friendly IP addresses such as
128.214.248.6.
5.5.1. What's in a name ?
You will probably be familiar with the appearance of Internet host
names, but may not understand how they are constructed, or
deconstructed. Internet domain names are heirarchial in nature, that
is, they have a tree-like structure. A `domain' is a family, or group
of names. A `domain' may be broken down into `subdomain'. A `toplevel
domain' is a domain that is not a subdomain. The Top Level Domains are
specified in RFC-920. Some examples of the most common top level
domains are:
COM
Commercial Organisations
EDU
Educational Organisations
GOV
Government Organisations
MIL
Millitary Organisations
ORG
Other organisations
Country Designator
these are two letters codes that represent a particular country.
Each of these top level domains has subdomains. The top level domains
based on country name are used next broken down into subdomains based
on the com, edu, gov, mil and org domains. So for example you end up
with: com.au and gov.au for commercial and government organisations in
Australia. For historical reasons most domains belonging to one of the
non-country based top level domains are for organisations within the
United States, although the United States also has its own country
code `.us'.
The next level of division usually represents the name of the
organisation. Further subdomains vary in nature, often the next level
of subdomain is based on the departmental structure of the
organisation but it may be based on any criterion considered
reasonable and meaningful by the network adminstrators for the
organisation.
The very left-most portion of the name is always the unique name
assigned to the host machine and is called the `hostname', the portion
of the name to the right of the hostname is called the `domainname'
and the complete name is called the `Fully Qualified Domain Name'.
To use my own email host as an example, the fully qualified domain
name is `perf.no.itg.telstra.com.au'. This means that the host name is
`perf' and the domain name is `no.itg.telstra.com.au'. The domain name
is based on a top level domain based on my country, Australia and as
my email address belongs to a commercial organisation we have `.com'
as the next level domain. The name of the company is (was) `telstra'
and our internal naming structure is based on organisational
structure, in my case, my machine belongs to the Information
Technology Group, Network Operations section.
5.5.2. What information you will need.
You will need to know what domain your hosts name will belong to. The
name resolver software provides this name translation service by
making requests to a `Domain Name Server', so you will need to know
the IP address of a local nameserver that you can use.
There are three files you need to edit, I'll cover each of these in
turn.
5.5.3. /etc/resolv.conf
The /etc/resolv.conf is the main configuration file for the name
resolver code. Its format is quite simple. It is a text file with one
keyword per line. There are three keywords typically used, they are:
domain
this keyword specifies the local domain name.
search
this keyword specifies a list of alternate domain names to
search for a hostname
nameserver
this keyword, which may be used many times, specifies an IP
address of a domain name server to query when resolving names
An example /etc/resolv.conf might look something like:
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
This example specifies that the default domain name to append to
unqualified names (ie hostnames supplied without a domain) is
maths.wu.edu.au and that if the host is not found in that domain to
also try the wu.edu.au domain directly. Two nameservers entry are sup
plied, each of which may be called upon by the name resolver code to
resolve the name.
5.5.4. /etc/host.conf
The /etc/host.conf file is where you configure some items that govern
the behaviour of the name resolver code. The format of this file is
described in detail in the `resolv+' man page. In nearly all
circumstances the following example will work for you:
order hosts,bind
multi on
This configuration tells the name resolver to check the /etc/hosts
file before attempting to query a nameserver and to return all valid
addresses for a host found in the /etc/hosts file instead of just the
first.
5.5.5. /etc/hosts
The /etc/hosts file is where you put the name and IP address of local
hosts. If you place a host in this file then you do not need to query
the domain name server to get its IP Address. The disadvantage of
doing this is that you must keep this file up to date yourself if the
IP address for that host changes. In a well managed system the only
hostnames that usually appear in this file are an entry for the
loopback interface and the local hosts name.
# /etc/hosts
127.0.0.1 localhost loopback
192.168.0.1 this.host.name
You may specify more than one host name per line as demonstrated by
the first entry, which is a standard entry for the loopback interface.
5.6. Configuring your loopback interface.
The `loopback' interface is a special type of interface that allows
you to make connections to yourself. There are various reasons why you
might want to do this, for example, you may wish to test some network
software without interfering with anybody else on your network. By
convention the IP address `127.0.0.1' has been assigned specifically
for loopback. So no matter what machine you go to, if you open a
telnet connection to 127.0.0.1 you will always reach the local host.
Configuring the loopback interface is simple and you should ensure you
do.
# ifconfig lo 127.0.0.1
# route add -host 127.0.0.1 lo
We'll talk more about the route command in the next section.
5.7. Routing.
Routing is a big topic. It is easily possible to write large volumes
of text about it. Most of you will have fairly simple routing
requirements, some of you will not. I will cover some basic
fundamentals of routing only. If you are interested in more detailed
information then I suggest you refer to the references provided at the
start of the document.
Let's start with a definition. What is IP routing ? Here is one that
I'm using:
IP Routing is the process by which a host with multiple net
work connections decides where to deliver IP datagrams it
has received.
It might be useful to illustrate this with an example. Imagine a
typical office router, it might have a PPP link off the Internet, a
number of ethernet segments feeding the workstations and another PPP
link off to another office. When the router receives a datagram on any
of its network connections, routing is the mechanism that it uses to
determine which interface it should send the datagram to next. Simple
hosts also need to route, all Internet hosts have two network devices,
one is the loopback interface described above and the other is the one
it uses to talk to the rest of the network, perhaps an ethernet,
perhaps a PPP or SLIP serial interface.
Ok, so how does routing work ? Each host keeps a special list of
routing rules, called a routing table. This table contains rows which
typically contain at least three fields, the first is a destination
address, the second is the name of the interface to which the datagram
is to be routed and the third is optionally the IP address of another
machine which will carry the datagram on its next step through the
network. In linux you can see this table by using the following
command:
# cat /proc/net/route
or by using either of the following commands:
# /sbin/route -n
# /bin/netstat -r
The routing process is fairly simple: an incoming datagram is
received, the destination address (who it is for) is examined and
compared with each entry in the table. The entry that best matches
that address is selected and the datagram is forwarded to the
specified interface. If the gateway field is filled then the datagram
is forwarded to that host via the specified interface, otherwise the
destination address is assumed to be on the network supported by the
interface.
To manipulate this table a special command is used. This command takes
command line arguments and converts them into kernel system calls that
request the kernel to add, delete or modify entries in the routing
table. The command is called `route'.
A simple example. Imagine you have an ethernet network. You've been
told it is a class-C network with an address of 192.168.1.0. You've
been supplied with an IP address of 192.168.1.10 for your use and have
been told that 192.168.1.1 is a router connected to the Internet.
The first step is to configure the interface as described earlier. You
would use a command like:
# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
You now need to add an entry into the routing table to tell the kernel
that datagrams for all hosts with addresses that match 192.168.1.*
should be sent to the ethernet device. You would use a command similar
to:
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
Note the use of the `-net' argument to tell the route program that
this entry is a network route. Your other choice here is a `-host'
route which is a route that is specific to one IP address.
This route will enable you to establish IP connections with all of the
hosts on your ethernet segment. But what about all of the IP hosts
that aren't on your ethernet segment ?
It would be a very difficult job to have to add routes to every
possible destination network, so there is a special trick that is used
to simplify this task. The trick is called the `default' route. The
default route matches every possible destination, but poorly, so that
if any other entry exists that matches the required address it will be
used instead of the default route. The idea of the default route is
simply to enable you to say "and everything else should go here". In
the example I've contrived you would use an entry like:
# route add default gw 192.168.1.1 eth0
The `gw' argument tells the route command that the next argument is
the IP address, or name, of a gateway or router machine which all
datagrams matching this entry should be directed to for further rout
ing.
So, your complete configuration would look like:
# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# route add default gw 192.168.1.1 eth0
If you take a close look at your network `rc' files you will find that
at least one of them looks very similar to this. This is a very common
configuration.
Let's now look at a slightly more complicated routing configuration.
Let's imagine we are configuring the router we looked at earlier, the
one supporting the PPP link to the Internet and the lan segments
feeding the workstations in the office. Lets imagine the router has
three ethernet segments and one PPP link. Our routing configuration
would look something like:
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
# route add default ppp0
Each of the workstations would use the simpler form presented above,
only the router needs to specify each of the network routes seperately
because for the workstations the default route mechanism will capture
all of them letting the router worry about splitting them up appropri
ately. You may be wondering why the default route presented doesn't
specify a `gw'. The reason for this is simple, serial link protocols
such as PPP and slip only ever have two hosts on their network, one at
each end. To specify the host at the other end of the link as the
gateway is pointless and redundant as there is no other choice, so you
do not need to specify a gateway for these types of network connec
tions. Other network types such as ethernet, arcnet or token ring do
require the gateway to be specified as these networks support large
numbers of hosts on them.
5.7.1. So what does the routed program do ?
The routing configuration described above is best suited to simple
network arrangements where there are only ever single possible paths
to destinations. When you have a more complex network arrangement
things get a little more complicated. Fortunately for most of you this
won't be an issue.
The big problem with `manual routing' or `static routing' as
described, is that if a machine or link fails in your network then the
only way you can direct your datagrams another way, if another way
exists, is by manually intervening and executing the appopriate
commands. Naturally this is clumsy, slow, impractical and hazard
prone. Various techniques have been developed to automatically adjust
routing tables in the event of network failures where there are
alternate routes, all of these techniques are loosely grouped by the
term `dynamic routing protocols'.
You may have heard of some of the more common dynamic routing
protocols. The most common are probably RIP (Routing Information
Protocol) and OSPF (Open Shortest Path First Protocol). The Routing
Information Protocol is very common on small networks such as small-
medium sized corporate networks or building networks. OSPF is more
modern and more capable at handling large network configurations and
better suited to environments where there is a large number of
possible paths through the network. Common implementations of these
protocols are: `routed' - RIP and `gated' - RIP, OSPF and others. The
`routed' program is normally supplied with your Linux distribution or
is included in the `NetKit' package detailed above.
An example of where and how you might use a dynamic routing protocol
might look something like the following:
192.168.1.0 / 192.168.2.0 /
255.255.255.0 255.255.255.0
- -
| |
| /-----\ /-----\ |
| | |ppp0 // ppp0| | |
eth0 |---| A |------//---------| B |---| eth0
| | | // | | |
| \-----/ \-----/ |
| \ ppp1 ppp1 / |
- \ / -
\ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
ppp0\ /ppp1
/-----\
| |
| C |
| |
\-----/
|eth0
|
|---------|
192.168.3.0 /
255.255.255.0
We have three routers A, B and C. Each supports one ethernet segment
with a Class C IP network (netmask 255.255.255.0). Each router also
has a PPP link to each of the other routers. The network forms a tri
angle.
It should be clear that the routing table at router A could look like:
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
This would work just fine until the link between router A and B should
fail. If that link failed then with the routing entry shown above
hosts on the ethernet segment of A could not reach hosts on the ether
net segment on B because their datagram would be directed to router
A's ppp0 link which is broken. They could still continue to talk to
hosts on the ethernet segment of C and hosts on the C's ethernet seg
ment could still talk to hosts on B's ethernet segment because the
link between B and C is still intact.
But wait, if A can talk to C and C can still talk to B, why shouldn't
A route its datagrams for B via C and let C send them to B ? This is
exactly the sort of problem that dynamic routing protocols like RIP
were designed to solve. If each of the routers A, B and C were running
a routing daemon then their routing tables would be automatically
adjusted to reflect the new state of the network should any one of the
links in the network fail. To configure such a network is simple, at
each router you need only do two things. In this case for Router A:
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# /usr/sbin/routed
The `routed' routing daemon automatically finds all active network
ports when it starts and sends and listens for messages on each of the
network devices to allow it to determine and update the routing table
on the host.
This has been a very brief explanation of dynamic routing and where
you would use it. If you want more information then you should refer
to the suggested references listed at the top of the document.
The important points relating to dynamic routing are:
1. You only need to run a dynamic routing protocol daemon when your
Lin
