Chapter 4. IP Address Allocation

Understanding static versus dynamic IP addressing (DHCP/BOOTP)

Table of Contents

Static IP addressing
Changing IP addresses on the fly
Plumbing a network card
Explain on-the-fly vs permanent changes (i.e. Changing Configuration files)
Dynamic Host Configuration Protocol
What is it?
Boot Protocol
How does DHCP work?
Why DHCP is restricted to a broadcast domain
Explain "dhclient"
How to obtain the address of the DHCP server
In Conclusion:

Static IP addressing

In Linux you need to set your IP address before you can communicate with anything on the network.

There are three ways of setting IP addresses in Linux.

  1. The first way is to set it statically and this obviously means that your network address will be set after rebooting the machine.

  2. The second means is to set your address on-the-fly. This means that, while the operating system is running, the IP address will be set. However, if one were to reboot the machine, this on-the-fly configuration will be removed and your network interface card will no longer have the IP address you set on-the-fly.

  3. Finally, we can leave our IP address unset and rely on DHCP to provide us an IP address. DHCP, which stands for Dynamic Host Configuration Protocol is a protocol that was designed to issue, reclaim and administer IP addresses in large and small networks. DHCP will issue IP addresses from a pool of addresses ensuring that there is a lease time on the address. When that lease expires, the client will ask for another IP address. Thus, your IP address may not be fixed but will vary from time to time. In general, this is a very handy means of assigning IP addresses and the most useful means of keeping track of them.

Within statically assigned addresses we can allow our address to be assigned by a DHCP server, which stands for Dynamic Host Configuration Protocol server. In this case the DHCP server assigns addresses (dynamically). The other way of setting a static address is choosing an address and setting it in a system file so that it doesn't change until the system is rebooted.

Changing IP addresses on the fly

What I'm going to do is show you how to set the IP address statically. Setting the IP address statically can be done using a file (in which case the IP address will remain across a reboot) or on-the-fly (in which case the IP address will revert to what is was initially after a reboot). I'm going to show you an on-the-fly set-up using the ifconfig command.

Ifconfig has a whole host of options to it, in Ethernet you need to tell it what Internet address to assign, this works right across all the distributions of Linux.

If we have the Ethernet card 0 with the IP address of 192.168.0.1 then we need to give it a netmask of 255.255.255.0. Once that 's set, if you do an 'ifconfig eth0' (this time without the IP address) you'll see that your IP address has changed and it 's now 192.168.0.1.

It might be worth just having a look at what other information shows up in that ifconfig eth0. We've seen earlier that your hardware address HWADDR shows up and that 's that 12 byte number, 00:01:03:8C:FB:01 (on my computer) number that indicates your MAC address.

It also shows you that the encapsulation later 1 protocol we're using in Ethernet. It shows up our INET address, which is the one we've just assigned. And the broadcast address.

Now from our earlier discussion on IP, our broadcast address is the address where the host portion is all 1 's or 0's. In this case our broadcast address is 192.168.0.255 and there 's the host portion - that is 1. If we take our IP address and we add this with our mask it shows us what network this host is on - in fact we use a standard class C network mask we know that the network with device is on is the 192.168.0 network. Then the next line we see "UP", indicating that this network is currently up.

We could for example run the "ifconfig eth0 -down" command and that would shut the network down and switch our network off.

Of course if we then did an "ifconfig eth0 up" the IP address that we set dynamically on-the-fly would be gone and we would have to run through the ifconfig command sequence again. There 's a whole bunch of other information there - broadcasts (in other words, this card is capable of broadcasting). It is also capable of multi-casting and there is the MTU ( Maximum Transmission Unit), and we saw earlier in the course that the MTU is 1500 bytes. The maximum units in size that Ethernet can carry. There is also a METRIC. A metric is now how many hops we need to get to the correct IP address (network) and in fact the metric here is 1.

Finally there 's information such as the number of received packets, number of errors, overruns, frame, number of transmitted packets, collisions, transmits and receipts of bytes.

All this information is important - without one of the tools working you can't run the network. For example if you get the interrupt incorrect, your network interface card cannot be seen by the operating system.

Plumbing a network card

We talked earlier about plumbing the network card and in this section we can do this on the fly.

Plumbing network card points to two different IP addresses or two different networks on the same network interface card.

In this case, eth0 interface is at the IP address 192.168.0.1 we could say, well eth0:1 must have the address 172.16.4.1.

This actually is using the Linux box as though it were a router, on the one side we've got one IP address and on the other side we've got another IP address.

How do we do that?

Do an ifconfig eth0, that is 192.168.0.1 netmask 255.255.255.0. If we do an ifconfig after plumbing the device, ( i.e. On eth0:1) it will set that to 172.16.4.1 with a netmask 255.255.255.0.

So, that 's the way of plumbing network interface cards. Again, because it 's on the fly if we shut our interface down, then both eth0 and eth0:1 IP addresses would be lost.

Why would we want to plumb a card?

Well, often we have one physical network and we want to separate that into two logical networks, we don't have an expensive system router so that 's the way to do it - you must plumb the card.

You'll know that from the discussions thus far that there are now two completely separate networks with a bridge in the middle.

Explain on-the-fly vs permanent changes (i.e. Changing Configuration files)

So far, we've done a whole lot of changes on-the-fly. We can also set these things statically so that after a re-boot the machine configuration stays the way it was set up. For this you need to look at a file called /etc/network/interfaces

In order to have the IP address stored in a file, in other words, we don't want to get it from DHCP and we don't want to have to configure it every time with an ifconfig command - we will need to edit a file.

The file in Debian is /etc/network/interfaces, and if we look at the interfaces in the file, it will have entries as shown below (or similar):

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo eth0
iface lo inet loopback

#mapping eth0
#       map WORK work-eth0

iface eth0 inet static
        address 192.168.10.1
        netmask 255.255.255.0
        gateway address 192.168.10.1
                
[Note] Note

This file is not in this location in SuSE (in SuSE, most things are changed through the tool YaST). In RedHat we need to edit a file called "/etc/sysconfig/network-scripts/ifcfg-eth0"

"iface eth0 inet static" will set the interface Ethernet0 and make it static and we could say here that the address is 192.168.0.1 netmask 255.255.255.0.

Once you set it statically you can say "ifdown eth0" and "ifup eth0" and that will re-start the network card for you whilst still having the same address. An interface will come up every time to use the same IP address.

I am going to change my system files as above.

Advantages And Dangers

As soon as I do that my Ethernet interface comes up and I should be able to see the rest of the network.

The danger of configuring network interfaces on-the-fly is that one might configure them and forget that you haven't make it permanent and only days or weeks later when the server 's been deleted, you find out that it was an on-the-fly configuration at which point you need to go and fix it.