[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ next ]


Debian GNU/Linux Network Administrator's Manual (Obsolete Documentation)
Chapter 3 - TCP/IP


author = Duncan C Thomson duncan@sciuro.demon.co.uk

topics = IP protocol, TCP protocol, IP addresses, IP interfaces, Routing


3.1 Intro

TCP/IP, as the name suggests, is a pair of protocols, and what most of the Internet is built on. Although physically the Internet is made up of a wide range of networking technologies, from slow modem links through Ethernet, to high-speed ATM-based switched networks, and a wide range of different applications run over it - the WWW and e-mail to name only two, the protocols which tie everything together are Internet Protocol (IP), and, perhaps almost as great an extent, Transmission Control Protocol. Another protocol, UDP, is used in place of TCP for some applications, especially in LAN environments, but on the Internet the TCP/IP partnership rules.

diagram: various physical networks, IP, TCP and UDP, apps

This chapter describes firstly the basics of IP networking, and later describes some of the more advanced features of TCP/IP available to the Debian user.


3.2 IP Addresses

Every computer connected directly to the Internet (or to any IP-based network) is identified by an IP address. IP addresses are four bytes long, and are usually written as four decimal numbers separated by dots, as in the examples below.

IP addresses typically identify two things. Firstly, they identify the network on which a particular computer is located. Secondly, they identify a particular computer on that network. Both these pieces of information are present in an IP address, and they can be called the network part and the host part. Two special values for the host part should be mentioned here - if the host part is all zeros, the address refers to a network (ie it is a network address as opposed to a host address). If, alternatively, the host part is all ones, the address refers to all hosts on the network (ie it is a broadcast address).

In order to identify which part of the IP address is the host part, and which part is the network part, there are two methods we can use. The first (and original) way is the easier by far to understand, so let's start by having a look at how it works. IP addresses are split into a number of classes, and it is this class which tells us how to split an IP address into its network and host parts.

Class A

A class A IP address has as its first byte a number between 1 and 126. The first byte of a class A IP address identifies the network, and the remaining three bytes identify the host.

Class B

A class B IP address has as its first byte a number between 128 and 191. Its first two bytes are the network identifier, and the remaining two bytes are the host identifier on that network.

Class C

A class C IP address has as its first byte a number between 192 and 223. Its first three bytes identify the network, and the remaining byte identifies an individual host on that network.

From the above list you might notice that IP addresses beginning with bytes from 224 and upwards are missing. These belong to other classes of IP address, not used for a normal IP host, and are beyond the discussion in this section.

You might also notice that IP addresses beginning with 127 are missing. IP addresses beginning with 127 are known as loopback addresses, and can be used for testing TCP/IP without actually having a network connection.

This is all very well, but what if we have been assigned a single class C address range, but want to split it among several networks? This is where the second method of specifying the network and host parts can be used. This method specifies, along with an IP address, a netmask, which has its bits set to one in the network part, and set to zero in the host part. So, for example, the default netmask for the various classes of network as as below:

Class A

255.0.0.0

Class B

255.255.0.0

Class C

255.255.255.0

These don't give us any new information beyond what the original address classes told us. The power in using netmasks, though, is that we can choose arbitrary splits between the network and host parts - for example, a netmask of 255.255.255.192 would allow us to split a class C network into four parts, each with 62 host addresses. Confused? Let's look at that example in more detail.

Let's suppose we've been allocated a class C network with IP addresses beginning with 192.168.50. If we convert the netmask 255.255.255.192 into binary, we can see that in the last byte, the first two bits are one (that is, they are included in the network part of the address) and the last six bits are zeros (that is, they form the host part). So, by using the IP addresses we have been given, along with this netmask, we have split our network into four, with network addresses given by setting these two bits to their four possible combinations (00, 01, 10, 11) while keeping the host part set to zeros (to identify the network):

Now we know where our four network addresses come from. What about our host addresses? They come from setting the host part in each subnet to all values from 000001 to 111110 (remember - all ones is a broadcast address). That gives us a total of 62 hosts in each network, with addresses:

In Linux, if we don't mention what netmask we are using, it's usually assumed by the software that we want to use the default netmask for that particular class of IP addresses. You should only need to specify a netmask if you are using one which is not the standard scheme for a particular class of IP addresses. It never does any harm to specify it though.

Each IP address should be unique on the Internet, or whichever IP network you are connected to. This means that your cannot assign IP addresses at random to your machines, since most IP addresses are already in use on the Internet. In order to get a legal set of IP addresses for your machines, you will normally go through an Internet Service Provider (ISP). If you have not been assigned such a range of addresses, you should use one of the range of private IP addresses, set aside for internet or testing use. Be aware that you will not be able to connect to the Internet directly from such a network; you will need to use some form of Network Address Translation (NAT) to do this. The ranges of IP addresses set aside for private use are:


3.3 IP Interface Configuration

Once we know what IP address we wish to use for our machine, we will have to bring up one of our network interfaces, and assign that IP address (possibly along with a netmask) to it. On most Debian systems this is done when installing the system, and you are seldom likely to need to change it on a simple system.

The ifconfig command is used to configure interfaces in order to use IP with them. There are a number of different network interfaces available with the Linux kernel, some of which are summarised below:

Loopback

The loopback interface (lo), usually configured as IP address 127.0.0.1

Ethernet

Ethernet interfaces (with names like eth0, eth1, eth2) are used to access Ethernet cards

PPP

PPP stands for Point-to-Point Protocol, and is used to run a variety of networking protocols, including IP, over any kind of serial lines (null modem, modem, ISDN). They have names like ppp0, ppp1

Token Ring

Token Ring devices are accessed with device names like tr0, tr1

Dummy

The dummy network drivers are used in systems who have an interface which is not always used, in order to provide a permanent IP interface for the relevant address. The device names are dummy, or dummy0, dummy1, and so on

There are a wide range of other network devices available, including SLIP, PLIP (serial and parallel line IP), `shaper' devices for controlling the traffic on certain interfaces, the ability to have several IP addresses on a single device, as well as frame relay, AX.25, X.25, ARCnet, LocalTalk and more. Here, though, we'll concentrate on one of the most common - the Ethernet interface.

In many cases, if you wish your kernel to automatically load modules for certain device drviers, you may require to make changes to your /etc/conf.modules or /etc/modules file. For example, to automatically load the NE2000 driver, you could have the line:

     alias eth0 ne

in your /etc/conf.modules file.

The simplest way to call ifconfig is to simply type its name:

     # /sbin/ifconfig
     lo        Link encap:Local Loopback  
               inet addr:127.0.0.1  Bcast:127.255.255.255  Mask:255.0.0.0
               UP BROADCAST LOOPBACK RUNNING  MTU:3584  Metric:1
               RX packets:18584 errors:0 dropped:0 overruns:0 frame:0
               TX packets:18584 errors:0 dropped:0 overruns:0 carrier:0
               Collisions:0

which simply returns information about the interfaces currently configured. If we wish now to bring up an Ethernet interface with the address 192.168.50.23, we'd specify the interface name and the IP address on ifconfig's command line:

     # /sbin/ifconfig eth0 192.168.50.23
     # /sbin/ifconfig
     lo        Link encap:Local Loopback  
               inet addr:127.0.0.1  Bcast:127.255.255.255  Mask:255.0.0.0
               UP BROADCAST LOOPBACK RUNNING  MTU:3584  Metric:1
               RX packets:18584 errors:0 dropped:0 overruns:0 frame:0
               TX packets:18584 errors:0 dropped:0 overruns:0 carrier:0
               Collisions:0 
     
     eth0      Link encap:Ethernet  HWaddr 00:00:E8:C5:64:2A  
               inet addr:192.168.50.23   Bcast:192.168.50.255  Mask:255.255.255.0
               UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
               RX packets:55 errors:0 dropped:0 overruns:0 frame:0
               TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
               Collisions:7 
               Interrupt:10 Base address:0x300

As can be seen from the example, the ifconfig now gives information about the new interface, including the netmask, network statistics, and information about the network driver itself. The ifconfig also allows the specification of a netmask when the interface is configured, for example:

     # /sbin/ifconfig eth0 192.168.50.23 netmask 255.255.255.192

Finally, to bring down an interface, use the following invocation of ifconfig:

     # /sbin/ifconfig eth0 down

Full information on the options available to ifconfig are available in the manual page - ifconfig(8).

If you set up the IP addressing on your machine when you installed Debian GNU/Linux, you should find that the ifconfig command is run automatically on bootup. This is done from the file /etc/init.d/network. Looking at this file should reveal a number of lines similar to the following:

     IPADDR=192.168.50.23
     NETMASK=255.255.255.0
     BROADCAST=192.168.50.255
     ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}

This is where the setting up of the Ethernet interface takes place. Above these lines, you should see a line setting up the loopback interface, and you should see a number of lines which appear to run a command called route. This program, and its function, is the subject of the next section.


3.4 Basic IP Routing

Once an IP interface has been set up, it is necessary that the Linux kernel be told where to send IP information for various machines on the IP network. The kernel holds a table, called a routing table, which lists a number of host or network addresses, along with information on how to send IP packets to these destinations.

The route command is use to examine or update this table. If only your loopback interface has been configured, this command used on its own will typically give output which looks something like the following:

     # /sbin/route
     Kernel IP routing table
     Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
     127.0.0.0       *               255.0.0.0       U     0      0        2 lo

This says that any traffic for the network identified as `127' should be routed through the loopback interface (lo). The `genmask' column specifies, in a similar way to a netmask, that this particular routing table entry should be used to match any IP address beginning with the number 127, no matter what the remainder is.

If our machine is connected to an Ethernet network, then typically we will want to make sure that the kernel routing table knows how to send information to this. Assuming we have set up our machine to be 192.168.50.23, with a default class C netmask, the following command will add a routing table entry for our local network:

     # /sbin/route add -net 192.168.50.0
     # /sbin/route
     Kernel IP routing table
     Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
     127.0.0.0       *               255.0.0.0       U     0      0        2 lo
     192.168.50.0    *               255.255.255.0   U     0      0      137 eth0

This tells the kernel that any IP addresses which start with 192.168.50 are on our local Ethernet network, and that they should be routed through the `eth0' interface. If you are using a non-standard netmask, this can be specified as a command line option to the route command:

     /sbin/route add -net 192.158.50.0 netmask 255.255.255.192

A command like one of the above would be sufficient if our TCP/IP network consisted of just a single network, not connected to anywhere else. However, the strengths of TCP/IP are its internetworking abilities, and normally a IP-based network consists of more than one network. In order to route IP packets from your machines to these other networks, you require to specify gateway hosts (often called routers) which deal with sending information to these other networks. There are in general two possibilities.

The first possibility is that we want to route IP packets to a specific network, and we know the address of a gateway host or router which deals with information for that network. Suppose, for example, that there is a machine 192.168.50.1 on our network, which is a router for the network 172.20.0.0 (a class B network). The following options to the route command specify this:

     # route add -net 172.20.0.0 gw 192.168.50.1

Since our routing table already contains an entry telling us how to send information to 192.168.50.1 (it's on our local network), any traffic for the remote network 172.20.0.0 is now sent to that machine, which deals with it appropriately.

The other possibility is that we use a certain gateway as a default route - a route used for all IP packets which don't match other rules in our routing table. If, for example, the machine with IP address 192.168.50.254 is our router to the rest of the world (the Internet, for example), we use the route command as follows:

     # /sbin/route add default gw 192.168.23.254

At this stage, let's have another look at our routing table:

     # /sbin/route
     Kernel IP routing table
     Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
     127.0.0.0       *               255.0.0.0       U     0      0        2 lo
     192.168.50.0    *               255.255.255.0   U     0      0      137 eth0
     172.20.0.0      192.168.50.1    255.255.0.0     UG    1      0        7 eth0
     default         192.168.50.254  0.0.0.0         UG    1      0       36 eth0

Going through the above table one line at a time:

  1. We first specify a loopback address for all 127.*.*.* addresses

  1. Next, we specify how to reach all machines on our local network, identified as 192.168.50.*

  1. Next, we give a route to all machines on the network (172.20.*.*) connected to the machine 192.168.50.1, which is a router (or gateway) for that network

  1. Finally, we specify that the machine 192.168.50.254 will deal with all other IP traffic

For now, we won't look at what the the various `flags', `metric' and `ref' entries mean.

Let's have another look at a typical /etc/init.d/network file, setup by Debian's installation procedure on a typical Ethernet-connected machine:

     #! /bin/sh
     ifconfig lo 127.0.0.1
     route add -net 127.0.0.0
     IPADDR=192.168.50.23
     NETMASK=255.255.255.0
     NETWORK=192.168.50.0
     BROADCAST=192.168.50.255
     GATEWAY=192.168.50.254
     ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}
     route add -net ${NETWORK}
     [ "${GATEWAY}" ] && route add default gw ${GATEWAY} metric 1

The first two lines of this shell script set up the loopback interface, and add an entry to the routing table for it. The variables which follow set up the IP address of our machine, the netmask, the address of our local network, the broadcast address, and the IP address of our default router. Finally, our local Ethernet interface is set up with ifconfig, and two invocations of the route command add routing table entries for firstly the local network and secondly our default gateway.

You may well find that the addresses (of networks and of machines) in the output from the route command do not appear as IP addresses, but are named. The names of networks can be set up in the /etc/networks file (which is normally set up by a Debian's network setup routines at installation times), and the names of hosts can come from a variety of machines, including the /etc/hosts file and the Domain Name Service (DNS). Let's now have a look at what DNS is and what it does.


3.5 Domain Name Service (DNS)

Every computer connected to the Internet, or any network using IP as its network protocol, has an IP address, in order that information be able to be routed correctly to and from it. IP addresses, though, are a bit difficult for humans to remember, and for this reason, each machine is also normally given a name. When you install Debian, this is one of the questions you will be asked - what the name of your computer will be.

The name of your computer will be stored in a few locations. You can find out the name of your computer by typing the hostname command, which returns the value in the file /etc/hostname. If you are connected to the Internet, this name will usually have several parts, separated from each other by dots, for example:

     debian.anon.com

It is only the first part of this which is the name of your own computer - the rest is known as the domain name - this is the anon.com part. Since there are likely to be several computers with the same name on the Internet, each one is made unique by putting it in its own domain. Within a domain, normally one person is responsible for giving out computers names, and administering a database which holds all the names and addresses of the computers in that domain. This system is known as DNS, and is like a telephone directory - you can look up a computer by name, and find out its IP address.

Before DNS, people had to remember IP addresses in order to use the Internet, and names were only known for a small subset of machines - typically the machines in the local network, and maybe one or two machines which were permanently connected to our site. These names were stored in a single file - /etc/hosts - and you'll normally find that your own machine's name and IP address were added to that file when Debian was installed.

DNS is a fairly complex system, and we'll look into more detail on it later, along with the software (bind) which allows you to look after your own DNS domain.

Here, though, we'll have a look at how DNS works from a client's point of view - ie from the point of view of a machine which only needs to look up machines in the DNS, rather than one which has to provide a DNS service.

When a Debian machine needs to look up another computer's name in order to find out its IP address, it uses a set of routines in the C library called the resolver. The resolver routines, in turn, consult firstly the file /etc/nsswitch.conf, which, against an entry for hosts will list the places that the resolver should check in order to find out the IP address. There are three possible entries here, and if more than one of them is present, the resolver will check each one in order. These entries are:

files

Check the file /etc/hosts for an entry for the particular hostname

nis

Check the NIS database (which we will look at later) for the hostname

dns

Check the Domain Name Service

A typical entry in /etc/nsswitch might be:

     hosts:         files dns

This tells the resolver to check firstly the file /etc/hosts and then query the DNS.

The DNS is configured by the file /etc/resolv.conf. This file normally specifies two things - firstly, the domain in which our machine is, and secondly, a number of nameservers to ask for information. An example would be:

     domain anon.org
     nameserver 172.19.0.1
     nameserver 172.19.5.1

The first line tells the resolver library that if we ask for a machine and don't specify a domain name, it should have anon.org appended to it - ie the resolver, assuming that the machine is in our own domain, should search it. The two lines beginning with nameserver specify the IP addresses of machines which we should query using DNS. These should always be IP addresses - not names - for obvious reasons.

Most networking utilities will automatically look up a machine's IP address if you specify a name, but if you want to query the DNS directly, the dnsutils package contains a program called nslookup. nslookup can be used either one-off, by giving the name of the machine you are searching for, possibly along with command-line arguments, or interactively, by just typing nslookup on its own. The interactive mode allows a number of searches to be made, and provides some limited help.

nslookup, along with other programs to query the DNS, and the software to provide a DNS service, will all be described in more detail later.

For more information on DNS, please see DNS/BIND, Chapter 8.


3.6 ICMP and IP Troubleshooting


3.7 TCP and UDP


3.8 Servers, Daemons and the Superserver


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ next ]


Debian GNU/Linux Network Administrator's Manual (Obsolete Documentation)

This manual is OBSOLETE and DEPRECATED since 2000, Instead see http://www.debian.org/doc/user-manuals#quick-reference

Ardo van Rangelrooij ardo.van.rangelrooij@tip.nl
Oliver Elphick olly@lfix.co.uk
Ivan E. Moore II rkrusty@debian.org
Duncan C. Thomson duncan@sciuro.demon.co.uk