====== DHCP Server problems ======

This deals with the DHCP Server in the Internet Gate, distributing IP addresses to clients on the LAN.\\
The DHCP Server is configured partly on the [[web_gui:network_page#DHCP Server|Network Configuration]] page, partly on the [[web_gui:dhcp_server|DHCP Server - Advanced]] page.

Read more: [[wp>DHCP|DHCP]]

===== IP address collisions =====

One of the nightmares on a local network (and indeed on any network) is when two PC:s or other devices (we call them //hosts//) start using the same IP address. 
The consequenses are characteristic but not so obvious for other than experienced network users: 
Suddenly an application, like "surfing", stops working for some time for one host. 
Then it starts working again, after a minute or so, but now the problem has moved to another host on the LAN. 
After some time again the problem jumps back to the first host, and so on.

The reason for this jumping error is that if two hosts act as if they have the same IP address it will confuse the router, in this case the Internet Gate who is set to work as their default gateway. 
The Internet Gate, as any router and host on a network, has a memory, the "ARP cache", that pairs an IP address with the host's MAC address. 
This memory is used for forwarding packets, destined to the particular IP address, to the correct unit. 
But for various reasons this memory has to be refreshed now and then, and this refresh is done by asking around on the network: "who has this particular IP address"? 
If there is more than one host out there answering this question, the Internet Gate may well get different answers from time to another, and as a result the traffic will jump around accordingly.

This IP address collision can happen if hosts on a LAN are assigned their IP addresses statically by a less careful network administrator. 
But if all hosts are getting their IP addresses dynamically by a DHCP server this should not happen, since the DHCP server is responsible in the first place for handing out unique IP addresses. 
Still, that can happen in two cases:
  - The DHCP server is not the only one on the network.
  - The DHCP server has forgotten all about the IP addresses that have been distributed.
These cases will be expanded below:

==== More than one DHCP server ====
The rule is simple enough: Avoid having more than one DHCP server on the LAN.

Using several DHCP servers would need a way for them to communicate with each other to synchronize their //IP lease databases//, that is, their opinions about which host that should get a particular IP address. 
Otherwise there is a considerable risk that the DHCP servers will give the same IP to different hosts, resulting in the IP collision scenario described above. 
Though there are standards proposed for such DHCP server synchronization, very few DHCP servers support this, nor does the Internet Gate. 

Having more than one DHCP server may not be a deliberate action. 
If the Internet Gate is added to a local network that already has a working DHCP server (maybe in a PC), it is important to shut the existing DHCP off.\\
Or, if one wants to keep the existing DHCP server, shut the DHCP server in the Internet Gate off (this is done on the [[web_gui:network_page#DHCP Server|Network page]]).\\
:!: If so, a static IP address that doesn't risk to conflict with a dynamic address (but still lies within the correct IP subnet) must be set on the Internet Gate, its local interfaces can never act as DHCP clients.

Likewise, if more than one Internet Gate is connected to the LAN (possibly for testing or for configuration purposes) all but one of them must first have its DHCP server shut off.

==== Lost IP lease database ====
The DHCP server does not actually have full control over the host's IP address usage, it merely gives out IP addresses when it is asked to do so by the clients (hosts) on the LAN. 
Each client is expected to renew its IP address regularly, at least within the agreed //lease time// but this can take hours. 
During that time there is no way for a DHCP server to forcefully make the client switch IP address. 
Thus, if the client has a "bad" address, it could take many minutes, even hours, before it is corrected by the server.

A consequence of this is that when a DHCP server (like the one in Internet Gate) is replaced by another, the new server has no way to know what IP addresses are used out there, nor can it do much to force new addresses upon the clients. 
The hosts keep on using their IP addresses, which they got from the old server, until the lease time is running out.
There is now a risk that the new DHCP server will give a host an IP address that is already in use on the network, and an IP collision is likely to happen.

This may be the scenario when for example an Internet Gate unit is replaced by a new one. 
Or the //lease database// is lost because a factory reset has been done on the Internet Gate. 
The solution is to disconnect //all// hosts from the LAN temporarily, and reconnect them again one-by-one so that each host in turn will get its IP address refreshed from the Internet Gate.\\
:?: In Windows, one can work with the ''ipconfig'' command in the Command Prompt. ''ipconfig /release'' followed by ''ipconfig /renew'' forces the acquisition of a new IP address from the DHCP server (should this not already have been done when the Ethernet link was coming up).

===== Can a client keep the same address? =====
An ideal network IP address policy is that it shouldn't matter which IP address a certain host gets. 
Nor should it matter whether it gets the same address all over again, after being restarted, or after being away from the network for some time (typically a temporary connected laptop). 
But the DHCP server in the Internet Gate is actually quite conservative: It tries to give the same IP address to a certain host (with a particular MAC address) all the time.

This is done by storing the pair //IP address / MAC address// in the permanent memory, so even if the Internet Gate is shut off this association will be remembered.
Consequently, it will avoid giving any of these stored IP addresses away to a new host entering the network, but keeping such a reserved address for the host (=MAC address) it "belongs" to.
In this way, the IP collision risk as described above is avoided, even after a restart of the Internet Gate.

Thus, in practise the host will keep the same IP address as long as the same Internet Gate unit is used, and its (permanent) //lease database// is not cleared. 
However, if keeping the same local IP address is really important for a host, it is more safe to enter that host into the **Fixed addresses** table on the [[web_gui:dhcp_server|DHCP Server - Advanced]] page.\\
:?: Alternatively, one can of course use a static IP address in the host, provided that the correct //default gateway// and //DNS address// (those should be set to the Internet Gate's IP address) are entered in the host. 
A task that is performed automatically if DHCP server **Fixed addresses** are used instead.


As a consequence of the permanent lease database memory, it is recommended to clear this memory if the Internet Gate unit is moved to a totally new environment, with new hosts on the LAN.
This is merely to free IP addresses for new usage, addresses that otherwise would be reserved for hosts not likely to show up.


===== Running out of IP addresses =====
The **From** and **To** fields on the [[web_gui:network_page#DHCP Server|Network page]] determine the size of the IP address store, the //pool//, from where the DHCP server can fetch an IP address to lend out to a host. 
The size of the pool is by default 31 such addresses (ranging from typically 192.168.0.31 to 192.168.0.61), but it can be augmented by changing the **From**/**To** IP addresses. 
The default size should be enough for most users. 

However, for a network that sees a lot of different users (=hosts) coming and going it is worth remembering that the pool of IP addresses includes the currently "invisible" hosts too, as has been described above about the permanent //lease database//. 
The DHCP server has a stategy that when a new host (with a previously unknown MAC address) appears, it will get an IP address that is totally unused, that is, it is not present in the stored //lease database//. 
Only when the server is running short of addresses, because the whole pool is used, it starts using IP addresses that really was reserved for another, currently unseen (=not connected) host, thus deleting the old host from the database.

===== Why can't my PC get an IP address? =====

  * Is there an Ethernet link at all, both in the PC and with the Internet Gate? (See also [[connect_to_gui|here]])
  * Does a static IP address work? To try that, set the IP interface of your PC to static instead of dynamic address (on Windows, this is done in the Control Panel, Network Connections). Choose an IP address that is within the same subnet as the Internet Gate's local interface (for example 192.168.0.5).
  * If the static IP address works, but not the dynamic (by DHCP, "Obtain an IP address automatically") check the following:
    * Is the address range too small in the Internet Gate? It could be increased on the [[web_gui:network_page#DHCP Server|Network page]].
    * Could there be an IP collision case, as described [[dhcp_server_problems#IP address collisions|above]]? Some DHCP clients, when getting a new IP address, check if anybody on the LAN answers on this address (by an ARP request), and refuse to use this address if it is found already in use by another host. If this is suspected, do:
      - Disconnect //all// hosts from the LAN
      - Click the **Reset** button under **IP address lease status** on the [[web_gui:dhcp_server#IP address lease status|DHCP Server - Advanced]] page.
      - Reconnect all hosts again one-by-one so that each host in turn will get its IP address refreshed from the Internet Gate.
    * If it is suspected that the //lease database// in the Internet Gate has been lost, or is wrong (maybe the unit has been moved to a new network, or factory reset), do the same procedure as above.
  * If the static IP address doesn't work either, check the cables and the IP address used (see also [[connect_to_gui|here]]). Only when this works, switch to a dynamic address in the PC.