2501 lines
106 KiB
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="UTF-8"?>
<sect1 id="Overview">
As with the rest of the Linux operating system and its numerous components
development of networking stack within Linux has been both a slow and
complex journey that has resembled that journey that has been faced by
people in the development of networking stacks of other operating systems
such as Microsoft Windows and Free BSD.
As has been stated in the Linux Networking HOWTO
the actual implementation of the TCP/IP protocol stack was done
basically from scratch due to concerns with regards to copyright issues
as well as the possibilty that developers would be able to come up
with a protocol stack that was superior to existing protocol stacks.
Ross Biro originally implemented the first ethernet driver for the
WD-8003 network interface card which led to an increase in pressure
among the open source community for the development of more complete
networking support. However, due to increased personal commitments he
was unable to continue to do so and soon after left this project
having formed a crucial base for the development of better networking
support under Linux.
Orest Zborowski <email>obz@Kodak.com</email> 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.
Soon after Laurence Culhane developed the first Linux drivers
to support the SLIP protocol which meant that an increasing
number of people were able to access the Internet from Linux.
It also led to a greater number of people who understood the
implications of what full networking support meant for Linux
which meant there was an increasing community of people who
went on to experiment with this software and further develop it.
Eventually Fred van Kempen took over the task of leading the
development of networking support under Linux. The primary
difference between himself and his former predecessors was that he
was far more ambitious in his desire to expand the Linux networking
code. He laid the plans for the development of a dynamic device
interface, Amateur Radio AX.25 protocol support and a more abstract
and modular networking implementation. Obviously, like his predecessor
there was increasing pressure on him to deliver a product that was
both reliable and satisfied the requirements of most users.
This issue was resolved by Alan Cox who eventually debugged the code
so that it was reliable enough to use in the general community.
He also became the new leader of the Linux networking effort.
Donald Becker then went on to make a name for himself through
his implementation of a huge range of ethernet drivers.
Alan continued to develop the networking code and through the aid of
other people added support for a multitude of other protocols such
as AX.25, IPX, PPP (Michael Callahan and Al Longyear), and AX.25/NetRom/Rose
protcol set (Jonathan Naylor).
While the current state of Linux networking is extremely stable (and
in some cases surpasses the capabilities and performance of commercial
implementations of Linux), there still seems to be significant issues with
regards to driver development. This is most especially the case with regards
to wireless driver development where while most internal cards are supported
there a small minority where support is non-existant and companies seem
to be unwilling to disclose enough information regarding the card to develop
something that is workeable.
Linux Networking HOWTO, http://tldp.org/HOWTO/NET3-4-HOWTO.html
5.1.4. IP Addresses, an Explanation.
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
Network Mask
Network Portion 192.168.110.
Host portion .23
----------------- ---------------
Network Address
Broadcast Address
----------------- ---------------
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
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 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 | | - |
| B | | - |
| C | | - |
|Multicast| | - |
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
Internet" 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:
| Network | Netmask | Network Addresses |
| Class | | |
| A | | - |
| B | | - |
| C | | - |
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 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
This line specifies the name of the shell script file that actually
manages the boot sequence. This file is somewhat equivalent to the
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
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 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.
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 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 netmask up
In this case I'm configuring an ethernet interface `eth0' with the IP
address `' and a network mask of `'. 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 `' and a
broadcast address of `' for the interface.
There are many other options to the ifconfig command. The most
important of these are:
up 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.
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
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 hierarchical 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:
Commercial Organizations
Educational Organizations
Government Organizations
Military Organizations
Other organizations
Internet-Related Organizations
Country Designator
these are two letters codes that represent a particular country.
For historical reasons most domains belonging to one of the non-
country based top level domains were used by organizations within the
United States, although the United States also has its own country
code `.us'. This is not true any more for .com and .org domains, which
are commonly used by non-us companies.
Each of these top level domains has subdomains. The top level domains
based on country name are often 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 organizations in
Australia; note that this is not a general rule, as actual policies
depend on the naming authority for each domain.
The next level of division usually represents the name of the
organization. Further subdomains vary in nature, often the next level
of subdomain is based on the departmental structure of the
organization but it may be based on any criterion considered
reasonable and meaningful by the network administrators for the
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 Terry's 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 his country, Australia and as his
email address belongs to a commercial organization, `.com' is there as
the next level domain. The name of the company is (was) `telstra' and
their internal naming structure is based on organizational structure,
in this case the machine belongs to the Information Technology Group,
Network Operations section.
Usually, the names are fairly shorter; for example, my ISP is called
``systemy.it'' and my non-profit organization is called ``linux.it'',
without any com and org subdomain, so that my own host is just called
``morgana.systemy.it'' and rubini@linux.it is a valid email address.
Note that the owner of a domain has the rights to register hostnames
as well as subdomains; for example, the LUG I belong to uses the
domain pluto.linux.it, because the owners of linux.it agreed to open a
subdomain for the LUG.
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
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:
this keyword specifies the local domain name.
this keyword specifies a list of alternate domain names to
search for a hostname
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
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
supplied, 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
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 localhost loopback 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.5.6. Running a name server
If you want to run a local nameserver, you can do it easily. Please
refer to the DNS-HOWTO and to any documents included in your version
of BIND (Berkeley Internet Name Domain).
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 `' has been assigned specifically
for loopback. So no matter what machine you go to, if you open a
telnet connection to you will always reach the local host.
Configuring the loopback interface is simple and you should ensure you
do (but note that this task is usually performed by the standard
initialization scripts).
root# ifconfig lo
root# route add -host 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
user% cat /proc/net/route
or by using either of the following commands:
user% /sbin/route -n
user% 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
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 You've
been supplied with an IP address of for your use and have
been told that is a router connected to the Internet.
The first step is to configure the interface as described earlier. You
would use a command like:
root# ifconfig eth0 netmask 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
root# route add -net netmask 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:
root# route add default gw 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
So, your complete configuration would look like:
root# ifconfig eth0 netmask up
root# route add -net netmask eth0
root# route add default gw 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
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:
root# route add -net netmask eth0
root# route add -net netmask eth1
root# route add -net netmask eth2
root# 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 separately
because for the workstations the default route mechanism will capture
all of them letting the router worry about splitting them up
appropriately. 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 connections. 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 appropriate
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: / /
- -
| |
| /-----\ /-----\ |
| | |ppp0 // ppp0| | |
eth0 |---| A |------//---------| B |---| eth0
| | | // | | |
| \-----/ \-----/ |
| \ ppp1 ppp1 / |
- \ / -
\ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
ppp0\ /ppp1
| |
| C |
| |
|---------| /
We have three routers A, B and C. Each supports one ethernet segment
with a Class C IP network (netmask Each router also
has a PPP link to each of the other routers. The network forms a
It should be clear that the routing table at router A could look like:
root# route add -net netmask eth0
root# route add -net netmask ppp0
root# route add -net netmask 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
ethernet 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 segment 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:
root# route add -net netmask eth0
root# /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
Linux machine has the possibility of selecting multiple possible
routes to a destination. An example of this would be if you plan
to use IP Masquerading.
2. The dynamic routing daemon will automatically modify your routing
table to adjust to changes in your network.
3. RIP is suited to small to medium sized networks.
5.8. Configuring your network servers and services.
Network servers and services are those programs that allow a remote
user to make user of your Linux machine. Server programs listen on
network ports. Network ports are a means of addressing a particular
service on any particular host and are how a server knows the
difference between an incoming telnet connection and an incoming ftp
connection. The remote user establishes a network connection to your
machine and the server program, the network daemon program, listening
on that port accepts the connection and executes. There are two ways
that network daemons may operate. Both are commonly employed in
practice. The two ways are:
the network daemon program listens on the designated network
port and when an incoming connection is made it manages the
network connection itself to provide the service.
slave to the inetd server
the inetd server is a special network daemon program that
specializes in managing incoming network connections. It has a
configuration file which tells it what program needs to be run
when an incoming connection is received. Any service port may be
configured for either of the tcp or udp protcols. The ports are
described in another file that we will talk about soon.
There are two important files that we need to configure. They are the
/etc/services file which assigns names to port numbers and the
/etc/inetd.conf file which is the configuration file for the inetd
network daemon.
5.8.1. /etc/services
The /etc/services file is a simple database that associates a human
friendly name to a machine friendly service port. Its format is quite
simple. The file is a text file with each line representing and entry
in the database. Each entry is comprised of three fields separated by
any number of whitespace (tab or space) characters. The fields are:
name port/protocol aliases # comment
a single word name that represents the service being described.
this field is split into two subfields.
a number that specifies the port number the named service will
be available on. Most of the common services have assigned
service numbers. These are described in RFC-1340.
this subfield may be set to either tcp or udp.
It is important to note that an entry of 18/tcp is very
different from an entry of 18/udp and that there is no technical
reason why the same service needs to exist on both. Normally
common sense prevails and it is only if a particular service is
available via both tcp and udp that you will see an entry for
other names that may be used to refer to this service entry.
Any text appearing in a line after a `#' character is ignored and
treated as a comment. An example /etc/services file.
All modern linux distributions provide a good /etc/services file.
Just in case you happen to be building a machine from the ground up,
here is a copy of the /etc/services file supplied with an old Debian
# /etc/services:
# $Id$
# Network services, Internet style
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
# Updated from RFC 1340, ``Assigned Numbers'' (July 1992). Not all ports
# are included, only the more common ones.
tcpmux 1/tcp # TCP port service multiplexer
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # message send protocol
msp 18/udp # message send protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
telnet 23/tcp
# 24 - private
smtp 25/tcp mail
# 26 - unassigned
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
re-mail-ck 50/tcp # Remote Mail Checking Protocol
re-mail-ck 50/udp # Remote Mail Checking Protocol
domain 53/tcp nameserver # name-domain server
domain 53/udp nameserver
mtp 57/tcp # deprecated
bootps 67/tcp # BOOTP server
bootps 67/udp
bootpc 68/tcp # BOOTP client
bootpc 68/udp
tftp 69/udp
gopher 70/tcp # Internet Gopher
gopher 70/udp
rje 77/tcp netrjs
finger 79/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
link 87/tcp ttylink
kerberos 88/tcp kerberos5 krb5 # Kerberos v5
kerberos 88/udp kerberos5 krb5 # Kerberos v5
supdup 95/tcp
# 100 - reserved
hostnames 101/tcp hostname # usually from sri-nic
iso-tsap 102/tcp tsap # part of ISODE.
csnet-ns 105/tcp cso-ns # also used by CSO name server
csnet-ns 105/udp cso-ns
rtelnet 107/tcp # Remote Telnet
rtelnet 107/udp
pop-2 109/tcp postoffice # POP version 2
pop-2 109/udp
pop-3 110/tcp # POP version 3
pop-3 110/udp
sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP
auth 113/tcp authentication tap ident
sftp 115/tcp
uucp-path 117/tcp
nntp 119/tcp readnews untp # USENET News Transfer Protocol
ntp 123/tcp
ntp 123/udp # Network Time Protocol
netbios-ns 137/tcp # NETBIOS Name Service
netbios-ns 137/udp
netbios-dgm 138/tcp # NETBIOS Datagram Service
netbios-dgm 138/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp
imap2 143/tcp # Interim Mail Access Proto v2
imap2 143/udp
snmp 161/udp # Simple Net Mgmt Proto
snmp-trap 162/udp snmptrap # Traps for SNMP
cmip-man 163/tcp # ISO mgmt over IP (CMOT)
cmip-man 163/udp
cmip-agent 164/tcp
cmip-agent 164/udp
xdmcp 177/tcp # X Display Mgr. Control Proto
xdmcp 177/udp
nextstep 178/tcp NeXTStep NextStep # NeXTStep window
nextstep 178/udp NeXTStep NextStep # server
bgp 179/tcp # Border Gateway Proto.
bgp 179/udp
prospero 191/tcp # Cliff Neuman's Prospero
prospero 191/udp
irc 194/tcp # Internet Relay Chat
irc 194/udp
smux 199/tcp # SNMP Unix Multiplexer
smux 199/udp
at-rtmp 201/tcp # AppleTalk routing
at-rtmp 201/udp
at-nbp 202/tcp # AppleTalk name binding
at-nbp 202/udp
at-echo 204/tcp # AppleTalk echo
at-echo 204/udp
at-zis 206/tcp # AppleTalk zone information
at-zis 206/udp
z3950 210/tcp wais # NISO Z39.50 database
z3950 210/udp wais
ipx 213/tcp # IPX
ipx 213/udp
imap3 220/tcp # Interactive Mail Access
imap3 220/udp # Protocol v3
ulistserv 372/tcp # UNIX Listserv
ulistserv 372/udp
# UNIX specific services
exec 512/tcp
biff 512/udp comsat
login 513/tcp
who 513/udp whod
shell 514/tcp cmd # no passwords used
syslog 514/udp
printer 515/tcp spooler # line printer spooler
talk 517/udp
ntalk 518/udp
route 520/udp router routed # RIP
timed 525/udp timeserver
tempo 526/tcp newdate
courier 530/tcp rpc
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/udp # -for emergency broadcasts
uucp 540/tcp uucpd # uucp daemon
remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem
klogin 543/tcp # Kerberized `rlogin' (v5)
kshell 544/tcp krcmd # Kerberized `rsh' (v5)
kerberos-adm 749/tcp # Kerberos `kadmin' (v5)
webster 765/tcp # Network dictionary
webster 765/udp
# From ``Assigned Numbers'':
#> The Registered Ports are not controlled by the IANA and on most systems
#> can be used by ordinary user processes or programs executed by ordinary
#> users.
#> Ports are used in the TCP [45,106] to name the ends of logical
#> connections which carry long term conversations. For the purpose of
#> providing services to unknown callers, a service contact port is
#> defined. This list specifies the port used by the server process as its
#> contact port. While the IANA can not control uses of these ports it
#> does register or list uses of these ports as a convenience to the
#> community.
ingreslock 1524/tcp
ingreslock 1524/udp
prospero-np 1525/tcp # Prospero non-privileged
prospero-np 1525/udp
rfe 5002/tcp # Radio Free Ethernet
rfe 5002/udp # Actually uses UDP only
bbs 7000/tcp # BBS service
# Kerberos (Project Athena/MIT) services
# Note that these are for Kerberos v4 and are unofficial. Sites running
# v4 should uncomment these and comment out the v5 entries above.
kerberos4 750/udp kdc # Kerberos (server) udp
kerberos4 750/tcp kdc # Kerberos (server) tcp
kerberos_master 751/udp # Kerberos authentication
kerberos_master 751/tcp # Kerberos authentication
passwd_server 752/udp # Kerberos passwd server
krb_prop 754/tcp # Kerberos slave propagation
krbupdate 760/tcp kreg # Kerberos registration
kpasswd 761/tcp kpwd # Kerberos "passwd"
kpop 1109/tcp # Pop with Kerberos
knetd 2053/tcp # Kerberos de-multiplexor
zephyr-srv 2102/udp # Zephyr server
zephyr-clt 2103/udp # Zephyr serv-hm connection
zephyr-hm 2104/udp # Zephyr hostmanager
eklogin 2105/tcp # Kerberos encrypted rlogin
# Unofficial but necessary (for NetBSD) services
supfilesrv 871/tcp # SUP server
supfiledbg 1127/tcp # SUP debugging
# Datagram Delivery Protocol services
rtmp 1/ddp # Routing Table Maintenance Protocol
nbp 2/ddp # Name Binding Protocol
echo 4/ddp # AppleTalk Echo Protocol
zip 6/ddp # Zone Information Protocol
# Debian GNU/Linux services
rmtcfg 1236/tcp # Gracilis Packeten remote config server
xtel 1313/tcp # french minitel
cfinger 2003/tcp # GNU Finger
postgres 4321/tcp # POSTGRES
mandelspawn 9359/udp mandelbrot # network mandelbrot
# Local services
In the real world, the actual file is always growing as new services
are being created. If you fear your own copy is incomplete, I'd
suggest to copy a new /etc/services from a recent distribution.
5.8.2. /etc/inetd.conf
The /etc/inetd.conf file is the configuration file for the inetd
server daemon. Its function is to tell inetd what to do when it
receives a connection request for a particular service. For each
service that you wish to accept connections for you must tell inetd
what network server daemon to run and how to run it.
Its format is also fairly simple. It is a text file with each line
describing a service that you wish to provide. Any text in a line
following a `#' is ignored and considered a comment. Each line
contains seven fields separated by any number of whitespace (tab or
space) characters. The general format is as follows:
service socket_type proto flags user server_path server_args
is the service relevant to this configuration as taken from the
/etc/services file.
this field describes the type of socket that this entry will
consider relevant, allowable values are: stream, dgram, raw,
rdm, or seqpacket. This is a little technical in nature, but as
a rule of thumb nearly all tcp based services use stream and
nearly all udp based services use dgram. It is only very special
types of server daemons that would use any of the other values.
the protocol to considered valid for this entry. This should
match the appropriate entry in the /etc/services file and will
typically be either tcp or udp. Sun RPC (Remote Procedure Call)
based servers will use rpc/tcp or rpc/udp.
there are really only two possible settings for this field.
This field setting tells inetd whether the network server
program frees the socket after it has been started and therefore
whether inetd can start another one on the next connection
request, or whether inetd should wait and assume that any server
daemon already running will handle the new connection request.
Again this is a little tricky to work out, but as a rule of
thumb all tcp servers should have this entry set to nowait and
most udp servers should have this entry set to wait. Be warned
there are some notable exceptions to this, so let the example
guide you if you are not sure.
this field describes which user account from /etc/passwd will be
set as the owner of the network daemon when it is started. This
is often useful if you want to safeguard against security risks.
You can set the user of an entry to the nobody user so that if
the network server security is breached the possible damage is
minimized. Typically this field is set to root though, because
many servers require root privileges in order to function
this field is pathname to the actual server program to execute
for this entry.
this field comprises the rest of the line and is optional. This
field is where you place any command line arguments that you
wish to pass to the server daemon program when it is launched. An example /etc/inetd.conf
As for the /etc/services file all modern distributions will include a
good /etc/inetd.conf file for you to work with. Here, for completeness
is the /etc/inetd.conf file from the Debian distribution.
# /etc/inetd.conf: see inetd(8) for further informations.
# Internet server configuration database
# Modified for Debian by Peter Tobias <tobias@et-inf.fho-emden.de>
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
# Internal services
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
discard stream tcp nowait root internal
discard dgram udp wait root internal
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
time stream tcp nowait root internal
time dgram udp wait root internal
# These are standard services.
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd
#fsp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.fspd
# Shell, login, exec and talk are BSD protocols.
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd
talk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.ntalkd
# Mail, news and uucp services.
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.smtpd
#nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/in.nntpd
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico
#comsat dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.comsat
# Pop et al
#pop-2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop3d
# `cfinger' is for the GNU finger server available for Debian. (NOTE: The
# current implementation of the `finger' daemon allows it to be run as `root'.)
#cfinger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.cfingerd
#finger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.fingerd
#netstat stream tcp nowait nobody /usr/sbin/tcpd /bin/netstat
#systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /boot
#bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
# Kerberos authenticated services (these probably need to be corrected)
#klogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k
#eklogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k -x
#kshell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd -k
# Services run ONLY on the Kerberos server (these probably need to be corrected)
#krbupdate stream tcp nowait root /usr/sbin/tcpd /usr/sbin/registerd
#kpasswd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/kpasswdd
# RPC based services
#mountd/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.mountd
#rstatd/1-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rstatd
#rusersd/2-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rusersd
#walld/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rwalld
# End of inetd.conf.
ident stream tcp nowait nobody /usr/sbin/identd identd -i
5.9. Other miscellaneous network related configuration files.
There are a number of miscellaneous files relating to network
configuration under linux that you might be interested in. You may
never have to modify these files, but it is worth describing them so
you know what they contain and what they are for.
5.9.1. /etc/protocols
The /etc/protocols file is a database that maps protocol id numbers
against protocol names. This is used by programmers to allow them to
specify protocols by name in their programs and also by some programs
such as tcpdump to allow them to display names instead of numbers in
their output. The general syntax of the file is:
protocolname number aliases
The /etc/protocols file supplied with the Debian distribution is as
# /etc/protocols:
# $Id$
# Internet (IP) protocols
# from: @(#)protocols 5.1 (Berkeley) 4/17/89
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # Internet Group Management
ggp 3 GGP # gateway-gateway protocol
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
st 5 ST # ST datagram mode
tcp 6 TCP # transmission control protocol
egp 8 EGP # exterior gateway protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
hmp 20 HMP # host monitoring protocol
xns-idp 22 XNS-IDP # Xerox NS IDP
rdp 27 RDP # "reliable datagram" protocol
iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4
xtp 36 XTP # Xpress Tranfer Protocol
ddp 37 DDP # Datagram Delivery Protocol
idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport
rspf 73 RSPF # Radio Shortest Path First.
vmtp 81 VMTP # Versatile Message Transport
ospf 89 OSPFIGP # Open Shortest Path First IGP
ipip 94 IPIP # Yet Another IP encapsulation
encap 98 ENCAP # Yet Another IP encapsulation
5.9.2. /etc/networks
The /etc/networks file has a similar function to that of the
/etc/hosts file. It provides a simple database of network names
against network addresses. Its format differs in that there may be
only two fields per line and that the fields are coded as:
networkname networkaddress
An example might look like:
When you use commands like the route command, if a destination is a
network and that network has an entry in the /etc/networks file then
the route command will display that network name instead of its
5.10. Network Security and access control.
Let me start this section by warning you that securing your machine
and network against malicious attack is a complex art. I do not
consider myself an expert in this field at all and while the following
mechanisms I describe will help, if you are serious about security
then I recommend you do some research of your own into the subject.
There are many good references on the Internet relating to the
subject, including the Security-HOWTO
An important rule of thumb is: `Don't run servers you don't intend to
use'. Many distributions come configured with all sorts of services
configured and automatically started. To ensure even a minimum level
of safety you should go through your /etc/inetd.conf file and comment
out (place a `#' at the start of the line) any entries for services
you don't intend to use. Good candidates are services such as: shell,
login, exec, uucp, ftp and informational services such as finger,
netstat and systat.
There are all sorts of security and access control mechanisms, I'll
describe the most elementary of them.
5.10.1. /etc/ftpusers
The /etc/ftpusers file is a simple mechanism that allows you to deny
certain users from logging into your machine via ftp. The
/etc/ftpusers file is read by the ftp daemon program (ftpd) when an
incoming ftp connection is received. The file is a simple list of
those users who are disallowed from logging in. It might looks
something like:
# /etc/ftpusers - users not allowed to login via ftp
5.10.2. /etc/securetty
The /etc/securetty file allows you to specify which tty devices root
is allowed to login on. The /etc/securetty file is read by the login
program (usually /bin/login). Its format is a list of the tty devices
names allowed, on all others root login is disallowed:
# /etc/securetty - tty's on which root is allowed to login
5.10.3. The tcpd hosts access control mechanism.
The tcpd program you will have seen listed in the same /etc/inetd.conf
provides logging and access control mechanisms to services it is
configured to protect.
When it is invoked by the inetd program it reads two files containing
access rules and either allows or denies access to the server it is
protecting accordingly.
It will search the rules files until the first match is found. If no
match is found then it assumes that access should be allowed to
anyone. The files it searches in sequence are: /etc/hosts.allow,
/etc/hosts.deny. I'll describe each of these in turn. For a complete
description of this facility you should refer to the appropriate man
pages (hosts_access(5) is a good starting point). /etc/hosts.allow
The /etc/hosts.allow file is a configuration file of the
/usr/sbin/tcpd program. The hosts.allow file contains rules describing
which hosts are allowed access to a service on your machine.
The file format is quite simple:
# /etc/hosts.allow
# <service list>: <host list> [: command]
service list
is a comma delimited list of server names that this rule applies
to. Example server names are: ftpd, telnetd and fingerd.
host list
is a comma delimited list of host names. You may also use IP
addresses here. You may additionally specify hostnames or
addresses using wildcard characters to match groups of hosts.
Examples include: gw.vk2ktj.ampr.org to match a specific host,
.uts.edu.au to match any hostname ending in that string, 44. to
match any IP address commencing with those digits. There are
some special tokens to simplify configuration, some of these
are: ALL matches every host, LOCAL matches any host whose name
does not contain a `.' ie is in the same domain as your machine
and PARANOID matches any host whose name does not match its
address (name spoofing). There is one last token that is also
useful. The EXCEPT token allows you to provide a list with
exceptions. This will be covered in an example later.
is an optional parameter. This parameter is the full pathname of
a command that would be executed everytime this rule is matched.
It could for example run a command that would attempt to
identify who is logged onto the connecting host, or to generate
a mail message or some other warning to a system administrator
that someone is attempting to connect. There are a number of
expansions that may be included, some common examples are: %h
expands to the name of the connecting host or address if it
doesn't have a name, %d the daemon name being called.
An example:
# /etc/hosts.allow
# Allow mail to anyone
in.smtpd: ALL
# All telnet and ftp to only hosts within my domain and my host at home.
telnetd, ftpd: LOCAL, myhost.athome.org.au
# Allow finger to anyone but keep a record of who they are.
fingerd: ALL: (finger @%h | mail -s "finger from %h" root) /etc/hosts.deny
The /etc/hosts.deny file is a configuration file of the /usr/sbin/tcpd
program. The hosts.deny file contains rules describing which hosts are
disallowed access to a service on your machine.
A simple sample would look something like this:
# /etc/hosts.deny
# Disallow all hosts with suspect hostnames
# Disallow all hosts.
The PARANOID entry is really redundant because the other entry traps
everything in any case. Either of these entry would make a reasonable
default depending on your particular requirement.
Having an ALL: ALL default in the /etc/hosts.deny and then
specifically enabling on those services and hosts that you want in the
/etc/hosts.allow file is the safest configuration.
5.10.4. /etc/hosts.equiv
The hosts.equiv file is used to grant certain hosts and users access
rights to accounts on your machine without having to supply a
password. This is useful in a secure environment where you control all
machines, but is a security hazard otherwise. Your machine is only as
secure as the least secure of the trusted hosts. To maximize security,
don't use this mechanism and encourage your users not to use the
.rhosts file as well.
5.10.5. Configure your ftp daemon properly.
Many sites will be interested in running an anonymous ftp server to
allow other people to upload and download files without requiring a
specific userid. If you decide to offer this facility make sure you
configure the ftp daemon properly for anonymous access. Most man pages
for ftpd(8) describe in some length how to go about this. You should
always ensure that you follow these instructions. An important tip is
to not use a copy of your /etc/passwd file in the anonymous account
/etc directory, make sure you strip out all account details except
those that you must have, otherwise you will be vulnerable to brute
force password cracking techniques.
5.10.6. Network Firewalling.
Not allowing datagrams to even reach your machine or servers is an
excellent means of security. This is covered in depth in the Firewall-
HOWTO, and (more concisely) in a later section of this document.
5.10.7. Other suggestions.
Here are some other, potentially religious suggestions for you to
despite its popularity the sendmail daemon appears with
frightening regularity on security warning announcements. Its up
to you, but I choose not to run it.
NFS and other Sun RPC services
be wary of these. There are all sorts of possible exploits for
these services. It is difficult finding an option to services
like NFS, but if you configure them, make sure you are careful
with who you allow mount rights to.
6. IP- and Ethernet-Related Information
This section covers information specific to Ethernet and IP. These
subsections have been grouped together because I think they are the
most interesting ones in the formerly-called ``Technology Specific''
Section. Anyone with a LAN should be able to benefit from these
6.1. Ethernet
Ethernet device names are `eth0', `eth1', `eth2' etc. The first card
detected by the kernel is assigned `eth0' and the rest are assigned
sequentially in the order they are detected.
By default, the Linux kernel only probes for one Ethernet device, you
need to pass command line arguments to the kernel in order to force
detection of furter boards.
To learn how to make your ethernet card(s) working under Linux you
should refer to the Ethernet-HOWTO.
Once you have your kernel properly built to support your ethernet card
then configuration of the card is easy.
Typically you would use something like (which most distributions
already do for you, if you configured them to support your ethernet):
root# ifconfig eth0 netmask up
root# route add -net netmask eth0
Most of the ethernet drivers were developed by Donald Becker,
6.8. IPIP Encapsulation
Why would you want to encapsulate IP datagrams within IP datagrams? It
must seem an odd thing to do if you've never seen an application of it
before. Ok, here are a couple of common places where it is used:
Mobile-IP and IP-Multicast. What is perhaps the most widely spread use
of it though is also the least well known, Amateur Radio.
Kernel Compile Options:
Networking options --->
[*] TCP/IP networking
[*] IP: forwarding/gatewaying
<*> IP: tunneling
IP tunnel devices are called `tunl0', `tunl1' etc.
"But why ?". Ok, ok. Conventional IP routing rules mandate that an IP
network comprises a network address and a network mask. This produces
a series of contiguous addresses that may all be routed via a single
routing entry. This is very convenient, but it means that you may
only use any particular IP address while you are connected to the
particular piece of network to which it belongs. In most instances
this is ok, but if you are a mobile netizen then you may not be able
to stay connected to the one place all the time. IP/IP encapsulation
(IP tunneling) allows you to overcome this restriction by allowing
datagrams destined for your IP address to be wrapped up and redirected
to another IP address. If you know that you're going to be operating
from some other IP network for some time you can set up a machine on
your home network to accept datagrams to your IP address and redirect
them to the address that you will actually be using temporarily.
6.8.1. A tunneled network configuration.
192.168.1/24 192.168.2/24
- -
| ppp0 = ppp0 = |
| aaa.bbb.ccc.ddd fff.ggg.hhh.iii |
| |
| /-----\ /-----\ |
| | | // | | |
|---| A |------//---------| B |---|
| | | // | | |
| \-----/ \-----/ |
| |
- -
The diagram illustrates another possible reason to use IPIP encapsula­
tion, virtual private networking. This example presupposes that you
have two machines each with a simple dial up internet connection. Each
host is allocated just a single IP address. Behind each of these
machines are some private local area networks configured with reserved
IP network addresses. Suppose that you want to allow any host on net­
work A to connect to any host on network B, just as if they were prop­
erly connected to the Internet with a network route. IPIP encapsula­
tion will allow you to do this. Note, encapsulation does not solve the
problem of how you get the hosts on networks A and B to talk to any
other on the Internet, you still need tricks like IP Masquerade for
that. Encapsulation is normally performed by machine functioning as
Linux router `A' would be configured with a script like the following:
# Ethernet configuration
ifconfig eth0 netmask $mask up
route add -net netmask $mask eth0
# ppp0 configuration (start ppp link, set default route)
route add default ppp0
# Tunnel device configuration
ifconfig tunl0 up
route add -net netmask $mask gw $remotegw tunl0
Linux router `B' would be configured with a similar script:
# Ethernet configuration
ifconfig eth0 netmask $mask up
route add -net netmask $mask eth0
# ppp0 configuration (start ppp link, set default route)
route add default ppp0
# Tunnel device configuration
ifconfig tunl0 up
route add -net netmask $mask gw $remotegw tunl0
The command:
route add -net netmask $mask gw $remotegw tunl0
reads: `Send any datagrams destined for inside an IPIP
encap datagram with a destination address of aaa.bbb.ccc.ddd'.
Note that the configurations are reciprocated at either end. The
tunnel device uses the `gw' in the route as the destination of the IP
datagram in which it will place the datagram it has received to route.
That machine must know how to decapsulate IPIP datagrams, that is, it
must also be configured with a tunnel device.
6.8.2. A tunneled host configuration.
It doesn't have to be a whole network you route. You could for example
route just a single IP address. In that instance you might configure
the tunl device on the `remote' machine with its home IP address and
at the A end just use a host route (and Proxy Arp) rather than a
network route via the tunnel device. Let's redraw and modify our
configuration appropriately. Now we have just host `B' which to want
to act and behave as if it is both fully connected to the Internet and
also part of the remote network supported by host `A':
| ppp0 = ppp0 =
| aaa.bbb.ccc.ddd fff.ggg.hhh.iii
| /-----\ /-----\
| | | // | |
|---| A |------//---------| B |
| | | // | |
| \-----/ \-----/
| also:
Linux router `A' would be configured with:
# Ethernet configuration
ifconfig eth0 netmask $mask up
route add -net netmask $mask eth0
# ppp0 configuration (start ppp link, set default route)
route add default ppp0
# Tunnel device configuration
ifconfig tunl0 up
route add -host gw $remotegw tunl0
# Proxy ARP for the remote host
arp -s xx:xx:xx:xx:xx:xx pub
Linux host `B' would be configured with:
# ppp0 configuration (start ppp link, set default route)
route add default ppp0
# Tunnel device configuration
ifconfig tunl0 up
route add -net netmask $mask gw $remotegwtunl0
This sort of configuration is more typical of a Mobile-IP application.
Where a single host wants to roam around the Internet and maintain a
single usable IP address the whole time. You should refer to the
Mobile-IP section for more information on how that is handled in
6.9. IP Masquerade
Many people have a simple dialup account to connect to the Internet.
Nearly everybody using this sort of configuration is allocated a
single IP address by the Internet Service Provider. This is normally
enough to allow only one host full access to the network. IP
Masquerade is a clever trick that enables you to have many machines
make use of that one IP address, by causing the other hosts to look
like, hence the term masquerade, the machine supporting the dialup
connection. There is a small caveat and that is that the masquerade
function nearly always works only in one direction, that is the
masqueraded hosts can make calls out, but they cannot accept or
receive network connections from remote hosts. This means that some
network services do not work such as talk and others such as ftp must
be configured to operate in passive (PASV) mode to operate.
Fortunately the most common network services such as telnet, World
Wide Web and irc do work just fine.
Kernel Compile Options:
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
Networking options --->
[*] Network firewalls
[*] TCP/IP networking
[*] IP: forwarding/gatewaying
[*] IP: masquerading (EXPERIMENTAL)
Normally you have your linux machine supporting a slip or PPP dialup
line just as it would if it were a standalone machine. Additionally it
would have another network device configured, perhaps an ethernet,
configured with one of the reserved network addresses. The hosts to be
masqueraded would be on this second network. Each of these hosts would
have the IP address of the ethernet port of the linux machine set as
their default gateway or router.
A typical configuration might look something like this:
- -
\ |
\ | /
\ --------- |
| | Linux | .1.1 |
NET =================| masq |------|
| PPP/slip | router| | --------
/ --------- |--| host |
/ | | |
/ | --------
- -
Masquerading with IPFWADM
The most relevant commands for this configuration are:
# Network route for ethernet
route add -net netmask eth0
# Default route to the rest of the internet.
route add default ppp0
# Cause all hosts on the 192.168.1/24 network to be masqueraded.
ipfwadm -F -a m -S -D
Masquerading with IPCHAINS
This is similar to using IPFWADM but the command structure has
# Network route for ethernet
route add -net netmask eth0
# Default route to the rest of the internet.
route add default ppp0
# Cause all hosts on the 192.168.1/24 network to be masqueraded.
ipchains -A forward -s -j MASQ
You can get more information on the Linux IP Masquerade feature from
the IP Masquerade Resource Page. Also, a very detailed document about
masquesrading is the ``IP-Masquerade mini-HOWTO'' (which also intructs
to configure other OS's to run with a Linux masquerade server).
6.10. IP Transparent Proxy
IP transparent proxy is a feature that enables you to redirect servers
or services destined for another machine to those services on this
machine. Typically this would be useful where you have a linux
machine as a router and also provides a proxy server. You would
redirect all connections destined for that service remotely to the
local proxy server.
Kernel Compile Options:
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
Networking options --->
[*] Network firewalls
[*] TCP/IP networking
[*] IP: firewalling
[*] IP: transparent proxy support (EXPERIMENTAL)
Configuration of the transparent proxy feature is performed using the
ipfwadm command
An example that might be useful is as follows:
root# ipfwadm -I -a accept -D 0/0 telnet -r 2323
This example will cause any connection attempts to port telnet (23) on
any host to be redirected to port 2323 on this host. If you run a
service on that port, you could forward telnet connections, log them
or do whatever fits your need.
A more interesting example is redirecting all http traffic through a
local cache. However, the protocol used by proxy servers is different
from native http: where a client connects to www.server.com:80 and
asks for /path/page, when it connects to the local cache it contacts
proxy.local.domain:8080 and asks for www.server.com/path/page.
To filter an http request through the local proxy, you need to adapt
the protocol by inserting a small server, called transproxy (you can
find it on the world wide web). You can choose to run transproxy on
port 8081, and issue this command:
root# ipfwadm -I -a accept -D 0/0 80 -r 8081
The transproxy program, then, will receive all connections meant to
reach external servers and will pass them to the local proxy after
fixing protocol differences.
6.11. IPv6
Just when you thought you were beginning to understand IP networking
the rules get changed! IPv6 is the shorthand notation for version 6 of
the Internet Protocol. IPv6 was developed primarily to overcome the
concerns in the Internet community that there would soon be a shortage
of IP addresses to allocate. IPv6 addresses are 16 bytes long (128
bits). IPv6 incorporates a number of other changes, mostly
simplifications, that will make IPv6 networks more managable than IPv4
Linux already has a working, but not complete, IPv6 implementation in
the 2.2.* series kernels.
If you wish to experiment with this next generation Internet
technology, or have a requirement for it, then you should read the
IPv6-FAQ which is available from www.terra.net.
6.12. Mobile IP
The term "IP mobility" describes the ability of a host that is able to
move its network connection from one point on the Internet to another
without changing its IP address or losing connectivity. Usually when
an IP host changes its point of connectivity it must also change its
IP address. IP Mobility overcomes this problem by allocating a fixed
IP address to the mobile host and using IP encapsulation (tunneling)
with automatic routing to ensure that datagrams destined for it are
routed to the actual IP address it is currently using.
A project is underway to provide a complete set of IP mobility tools
for Linux. The Status of the project and tools may be obtained from
the: Linux Mobile IP Home Page.
6.13. Multicast
IP Multicast allows an arbitrary number of IP hosts on disparate IP
networks to have IP datagrams simultaneously routed to them. This
mechanism is exploited to provide Internet wide "broadcast" material
such as audio and video transmissions and other novel applications.
Kernel Compile Options:
Networking options --->
[*] TCP/IP networking
[*] IP: multicasting
A suite of tools and some minor network configuration is required.
Please check the Multicast-HOWTO for more information on Multicast
support in Linux.
6.14. NAT - Network Address Translation
The IP Network Address Translation facility is pretty much the
standardized big brother of the Linux IP Masquerade facility. It is
specified in some detail in RFC-1631 at your nearest RFC archive. NAT
provides features that IP-Masquerade does not that make it eminently
more suitable for use in corporate firewall router designs and larger
scale installations.
An alpha implementation of NAT for Linux 2.0.29 kernel has been
developed by Michael.Hasenstein, Michael.Hasenstein@informatik.tu-
chemnitz.de. Michaels documentation and implementation are available
Linux IP Network Address Web Page
Newer Linux 2.2.x kernels also include some NAT functionality in the
routing algorithm.
6.15. Traffic Shaper - Changing allowed bandwidth
The traffic shaper is a driver that creates new interface devices,
those devices are traffic-limited in a user-defined way, they rely on
physical network devices for actual transmission and can be used as
outgoing routed for network traffic.
The shaper was introduced in Linux-2.1.15 and was backported to
Linux-2.0.36 (it appeared in 2.0.36-pre-patch-2 distributed by Alan
Cox, the author of the shaper device and maintainer of Linux-2.0).
The traffic shaper can only be compiled as a module and is configured
by the shapecfg program with commands like the following:
shapecfg attach shaper0 eth1
shapecfg speed shaper0 64000
The shaper device can only control the bandwidth of outgoing traffic,
as packets are transmitted via the shaper only according to the
routing tables; therefore, a ``route by source address'' functionality
could help in limiting the overall bandwidth of specific hosts using a
Linux router.
Linux-2.2 already has support for such routing, if you need it for
Linux-2.0 please check the patch by Mike McLagan, at ftp.invlogic.com.
Refer to Documentationnetworking/shaper.txt for further information
about the shaper.
If you want to try out a (tentative) shaping for incoming packets, try
out rshaper-1.01 (or newer), from ftp.systemy.it.
6.16. Routing in Linux-2.2
The latest versions of Linux, 2.2 offer a lot of flexibility in
routing policy. Unfortunately, you have to wait for the next version
of this howto, or go read the kernel sources.
There are four categories of high level abstract connections:
- point-to-point
- point-to-multipoint
- multipoint-to-point
- multipoint-to-multipoint
In network terminology the word "point" is usually synonymous with "device".
4. Networking hardware supported
Linux supports a great variety of networking hardware, including some
obsolete equipment.
Some interesting documents:
· Hardware HOWTO <http://metalab.unc.edu/mdw/HOWTO/Hardware-
· Ethernet HOWTO <http://metalab.unc.edu/mdw/HOWTO/Ethernet-
6.9. Authentication
There are also various ways of authenticating users in mixed networks.
· For Linux/Windows NT:http://www.mindware.com.au/ftp/smb-NT-
· The PAM (pluggable authentication module) which is a flexible
method of Unix authentication: PAM library
· Finally, LDAP in Linux
7. Remote execution of applications
One of the most amazing features of Unix (yet one of the most unknown
to new users) is its great support for remote and distributed
execution of applications.
7.2. Remote commands
In Unix, and in particular in Linux, remote commands exist that allow
for interaction with other computers from the shell prompt. Examples
are: rlogin, which allows for login in a remote machine in a similar
way to telnet, rcp, which allows for the remote transfer of files
among machines, etc. Finally, the remote shell command rsh allows the
execution of a command on a remote machine without actually logging
onto that machine.
2.2. What makes Linux different?
Why work on Linux? Linux is generally cheaper (or at least no more
expensive) than other operating systems and is frequently less
problematic than many commercial systems. But what makes Linux
different is not its price (after all, why would anyone want an OS -
even a free one - if it is not good enough?) but its outstanding
· Linux is a true 32-bit multitasking operating system, robust and
capable enough to be used in organizations ranging from
universities to large corporations.
· It runs on hardware ranging from low-end 386 boxes to massive
ultra-parallel machines in research centres.
· Out-of-the-box versions are available for Intel, Sparc, and Alpha
architectures, and experimental support exists for Power PC and
embedded systems, among others such as SGI, Ultra Sparc, AP1000+,
Strong ARM, and MIPS R3000/R4000.
· Finally, when it comes to networking, Linux is choice. Not only
because networking is tightly integrated with the OS itself and a
plethora of applications is freely available, but for the
robustness under heavy loads that can only be achieved after years
of debugging and testing in an Open Source project.
5. File Sharing and Printing
The primary purpose of many PC based Local Area Networks is to provide
file and printer sharing services to the users. Linux as a corporate
file and print server turns out to be a great solution.
8. Network Interconnection
Linux networking is rich in features. A Linux box can be configured so
it can act as a router, bridge, etc... Some of the available options
are described below.
Common Network Protocols
As mentioned earlier, network protocols are sets of rules and standards for data commnucations
over networks. A network architecture (such as Ethernet) can support multiple protocols, and even
multiple protocols currently.
Protocols are typically organized into protocol suites, or sets of compatible protocols. These are
also referred to as protocol stacks. A stack includes protocols for several different layers of the
OSI model. Lower-level protocols provide services for use by upper-level protocols. The highest
level protocols communicate directly with applications.
Communications protocols can be divided into two basic types, connection-orientated
and connectionless:
- Connection-orientated protocols
establish a connection, or virtual circuit, before, communicating, and disconnect it when
finished. Connection-orientated protocols generally have a lower speed due to the
bandwidth used for session maintenance.
- Connectionless protocols
do not establish a virtual circuit. Data is sent withoug establishing a connection, and may
be sent at any time. These protocols have low overhead, and are generally used where speed
is a high priority.
Another distinction between protocols is their reliablity. Some protocols send
acknowledgements for each transmitted packet. This makes for a more reliable connection,
but leaves less bandwidth for actual data transmission. These are called reliable protocols.
Protocols without acknowledgements are known as unreliable, although this does not
necessarily mean they are undependable.
Common Network Protocols and Characteristics
Protocol Overhead Routable? Typical Application
TCP/IP Medium Yes Large networks; Internet and UNIX compatibility
NetBEUI Low No Small Windows-based networks
IPX/SPX Medium Yes NetWare compatiblity
Appletalk Medium Yes Apple Macintosh compatiblity
DLC Medium No IBM mainframe compatiblity; some network printers
Common WAN Architectures
- Circuit Switching
Circuit switching is a connection-orientated method of communication. A circuit is dedicated to the connection,
and a connection must be specifically established when needed and disconnected when not needed.
- Message Switching
Message switching is a connectionless method of communication. Individual message units are sent across the network
with routing information without establishing a dedicated nework.
- Packet Switching
Packet switching is a more efficient connectionless communication method. Packets (smaller than message units)
are sent individually and can follow different routes to their destination. Some packet switching systems use
virtual circuits for a logical connection, but don't use a dedicated physical connection.
Switched networks are generally less expensive and allow networking with multiple locations; non-switched
lnks are usually dedicated between two locations and provide more consistent available bandwidth.
WAN connections typically require different (and more expensive) hardware than LAN connections. Typical
WAN equipment includes specialized types of routers, CSU/DSUs (Channel Service Unit/Digital Service Unit),
and multiplexers, which combine multiple signals (such as voice and data) for tranmissions on a single WAN
connection. A number of WAN technologies and public networks are available. FDDI, explained earlier in this
chapter, can also be used for wide-are networks. The common WAN technologies are described in detail in
the sections below.
3.5. WAN Networking: X.25, Frame-relay, etc...
Several third parties provide T-1, T-3, X.25 and Frame Relay products
for Linux. Generally special hardware is required for these types of
connections. Vendors that provide the hardware also provide the
drivers with protocol support.
· WAN resources for Linux:
>Start Binh
Attentuation is a physical phenomenon which causes a signal to gradually lose
power as it propogates through a medium. This is mainly due to due to two
factors, signal dispersion and signal absorption. Unfortunately, there is some
noise which generates a constant noise power, N, and so eventually, as the
signal travels a long enough distance, the signal poower will decrease to a
value less than the noise power.
This is similar to the effect observed when you are attempting to communicate
with another person with your natural voice. As the person moves further away
the voice is harder to hear as the signal power spreads out and is absorbed
by obstacles, etc....
Attenuation is generally a factor of distance and frequency.
This is very much in accordance with our current laws of physics.
The intensity if a signal is inversely proportional to the inverse square of the the signal distance.
You'll often notice that in military applications the usage of broad
frequency radar for spotting targets over great ranges and then the utilisation
of higher frequency signals as greater precision positioning is required.
Most transmission medium will have a rating which gives the attenuation as a
function of frequency and distance, eg. the attenuation per kilometer. Ideally
the attenuation is zero because this represents no loss in the signal power.
This leads us to the issue of digital transmission versus analogue
transmission. The primary advantage of digital transmission over analogue
transmission is the reduction in noise. The digital transmission system
reduces noise over successive transmissions because small variations in
the signal can be rounded off to the nearest level. Analogue transmission
systems need to filter out the noise, but the filter itself can sometimes
be a source of noise and generally, noise can accumulate to an unacceptable
level in an analogue tranmission system.
Consider two types of repeater to understand of digital transmission. In the
first instance (analogue) the situation is roughly synonymous with someone
who doesn't know Korean and who is trying to relay a message from one Korean
to another. It can be done if the person simply repeats the sounds that are
heard. In digital tranmission repitition would be more along the lines of
someone knowing Korean and actually "re-saying" what was heard (perhaps even
correcting for errors in what was heard).
Systems which transmit ananlogue signals (such as the calssical radio and
television broadcasting systems) can use one of three well known techniques,
Amplitude Modulation (AM), Frequency Modulation (FM), and Phase Modulation (PM).
AM works by varying the amplitude of a signal to code the bit stream. FM works
by varying frequency of a signal to code the bit stream. PM works by varying
the phase of a signal to code the bit stream.
To allow two transmission medium (usually of the same type) to be directly
connected the concept of a switch was developed. A general switch can be
built from many basic switches and is somtimes referred to as a switching
fabric. A lot of research and development contines in an attempt to build
better switching fabrics.
A circuit switched network operates at the physical layer to provide a single,
continuous transmission medium between any two hosts or end devices in the
network. Circuit switching is perhaps the most straightforward approach to building
communication network. Computer networks didn't actually evolve using circuit
switching though circuit switching is being considered for certain computer
applications such as video and voice. Because circuit switching constucts a
single long transmission medium with at most analogue repeaters the end devices
(in this case telephones) are able to modulate the signal on the medium however
they choose. This is also why two modems can communicate with one another over
a telephone network.
Multiplexing is used to share a single transmission medium among a number of
individual transmissions. The demultiplexer just undoes what the multiplexer
does. Therefore the multiplexer and demultiplexer must directly cooperate.
Multiplexers and demultiplexers are not so much network devices are not so much
network devices but functionality that is contained within a network device.
Switches (in the sense described here) may be similarly categorized in this way.
The transmission medium can be multiplexed in the time domain, called TDM (Time Domain
Multiplexing), using a simple switch and clocked control. Because of delays incurred
in the transmission line, the clocks may need to be out of phase with one another.
See that with the TDM, the shared medium must be able to transmit at a bit rate
that equals (or is better than) the sum of input bit rates. The swithes must also
be able to switch fast enough.
The previous example was assuming a synchronous transmission mode. In general, bit
streams can be divided into DU's called cells. Cells are fixed in length so that the
receiver knows when one cell finishes and the next cell begins.
Alternatively there is ATM (Asynchronous Transmission Mode, ATM is also the name
given to a popular network layer device that uses this multiplexing technique.),
where signals are irregularly multiplexed. How does the receiver know what order
the signals were multiplexed in?
Additional information is needed in the multiplexed signal. One way is to add a
header or label to the front of each cell. The header identifies the cell.
Using a header means using additional bits, which becomes overhead. Thus, to reduce
the overhead the cells should be reasonably larger than the header. Cells for
modern ATM transmission systems are about 50 butes in size.
Because modulators can transmit signals at different frequency bands, it is possible
to transmit several signals at one, with each signal transmitted within a different
frequency band. In this case the different signals have been frequency domain multiplexed.
This is known as FDM, (Frequency Domain Multiplexing).
Similar to FDM, WDM (Wavelength Division Multiplexing) uses each wavelength of light to
transmit a signal. WDM is for fiber optic systems. The number of wavelengths per
fiber, currently available, is about 300. Each wavelength can carry about 10Gbps.
This makes 3Tbps. AT&amp;T predict that up to 1024 wavelengths may be available in the future.
The hub/optical hub is clearly an analogue device - input signals are reflected to all
outputs. It is also called passive, because it does not introduce any power to the signal
(otherwise it would be called active). Considering the hub as a device which repeats
input from an incoming signal on all outputs is quite simplistic however the basic
function should be understandable. When examining the Data-link layer it will become
clearer how computers communicate using a hub. For wireless communication, the
transmission of each device is implicity received by every other device. This is an
implicit hub.
Wireless communication usually takes place using the IEEE 802.11 standard which specifies
an unlicensed radio spectrum at 2.4GHz and provides wireless Ethernet access at 11Mbps.
There is also some spectrum allocated between 5GHz ad 6GHz that provides 54Mbps.
Sophisticated codes and frequency sharing technology is used to maximise the usage of
this communication medium. This topic is strictly concerned with Medium Access Control,
to be discussed later. Wireless also allows point-to-point communication in the sense
that each point-to-point link or channel is a dedicated frequency range that no other
pair of devices will use.
Analogue telephone networks use conventional circuit switching networks to
construct a connection between two telephones. You have seen that a modem
converts digital signals to analogue to be transmitted over an analogue
telephone network.
Digital telephone networks use a codec or coder-decoder to convert analogue
telephone (or modem) signals into digital form! This is so that new digital
techniques can be used within a conventionally an analogue network, ie.
transparently to the analogue devices. The codec is used to convert from
analogue to digital and digital to analogue.
Enough is known now to consider the complexity of a large digital network
that supporst communication of various kinds. As technologies improve some
networks become more dominant than others. In todays world we see a
significant shift towards computer networks, away from conventional
telecommunication networks.
This doesn't mean the end of telecommunications, but rather a collapse of
outdated technological layers towards the "core" networks that they connect
to. It will become more apparent to you as we progres through this subject
that networks can be built on top of other networks which are themseleves
built on top of ther networks.
The size and scale of a network can vary substantially from Local Area Networks
(LANs) which usually connect 10-15 computers in a
small area (usually a small building) to Metropolitan Area Networks (MANs)
which use long-distance links (such as telephone lines or dedicated media)
to connect two or more locations within a single city or metropolitan area
to Wide Area Networks (WANs) which use the same technology as MANs to
connect computers in distant locations but in different cities
or even different countries.
There are two basic types of networks: client-server networks, which use
dedicated servers; and peer-to-peer networks, which (normally) share files
between workstations.
Server-based networks (also called client-server networks) use a dedicated
server machine which provides files and printers to network workstations
called clients. Client machines are simply used by network users, and usually
do not share files or printers. The key benefit of the server-client model is
in centralization. There is only a single point of control for network acccess,
security, and management. The disadvantages of a server-based network are the
higher cost of dedicated servers and network operating systems, as well as the
increased level of administrative effort required.
Conversely, peer-to-peer networks consist solely of workstations called peers.
Each workstation can be used by a user, and can also make shared files or
printers available to users at other workstations. The advantages of peer
networks include their ease of installation and use, their relative
inexpensiveness in comparison with server-based networks (since a dedicated
server is not required) and the fact that an administrator mightn't be required
(if users are able to manage resource sharing). The primary disadvantage of
peer networks is the lack of a central control mechanism. Each user controls
access to their own workstation's shared files and printers. In a large scale
network, such a security policy is difficult to manage without
compromising security. Further, a workstation that is being accessed by peers
can also be slowed down, inconveniencing the user at that workstation. Hence,
its clear that this system is best suited to smaller networks.
<sect1 id="Internet">
Internet is not described as a network of any single kind. It can be construed
as a large set of heterogenous networks that support a certain set of protocols
(TCP/IP) and provide certain common services. A good way to learn about the
Internet is to use the Internet!
Linux is a great platform to act as an Intranet / Internet server. The
term Intranet refers to the application of Internet technologies
inside an organisation mainly for the purpose of distributing and
making available information inside the company. Internet and Intranet
services offered by Linux include mail, news, WWW servers and many
more that will be outlined further on in this document.