Let's say that you've been tasked with configuring a DHCP
server, so you need to put all of the configuration settings
into this server that other people can use to get
an automatic IP address config.
To be able to provide this information to your clients,
you need to create a DHCP scope.
The scope contains a number of different parameters.
Perhaps the most important will be the IP address range
used by this particular section of the DHCP server,
along with any addresses that you would not
want to be assigned to individual workstations.
You'll also want to add the subnet mask for this network.
You want to put in the duration of the lease,
so you know exactly how long someone would
have one of these IP addresses.
And any other options that are important-- for example,
you may want to add DHCP servers, default gateway
information, the details on an IP address for your Voice
over IP gateways, or any other devices specific to the IP
configuration of your clients.
This grouping of IP addresses is called a pool,
and when a client needs an IP address,
it sends a request to the DHCP server,
and the DHCP server assigns an IP address
from any one that may be available in this pool.
A DHCP server may also have a scope of addresses.
The scope is a single, contiguous pool of IP addresses
that can be chosen for this automatic assignment process.
Inside of the scope you can make exceptions.
So there may be certain IP addresses that you would not
assign to local clients.
Here's what this would look like on a Windows
Server that happens to have a DHCP server running
inside of it.
And you can see that I've created a single scope that
is 165.245.44.0, and inside of that scope
I would have an address pool.
I would be able to see address leases,
I can configure reservations, and I
can look at any of the options specific to that scope.
Many DHCP servers are configured with a dynamic assignment,
which means there's a large pool of addresses,
and when a client needs an IP address,
that address is assigned from that pool.
After the lease period is expired
and that device does not renew the lease,
then that IP address is added back to the available pool.
Many DHCP servers will also have an automatic assignment
process, which means that once the IP address has been
assigned to a workstation, that IP address will always
be available, if possible.
That way, if you leave and come back in a week,
you may be assigned exactly the same IP address
over and over and over again.
This makes the assignment process a bit easier,
although it does require additional overhead
and a larger pool to be able to support
all of these devices that may or may not currently
be on the network.
Instead of randomly assigning an IP address
from an available pool, we can also configure our DHCP server
to assign a static IP address.
This is especially useful if you have a server,
and you would like that server to have exactly the same IP
address every time it starts.
You would add the MAC address of that server
to the DHCP configuration, and assign it a matching IP
address.
Each time the file server makes a request
to the DHCP server for an IP address,
the MAC address is identified and exactly
the same IP address and configuration
is provided to that server every single time.
You may see this process referred to as a static DHCP
assignment, static DHCP, an address reservation or an IP
reservation.
Here's the address reservation process
on my local DHCP server.
This device is a router that has a DHCP server inside of it.
And its starting IP address is 192.168.1.2
through an ending IP address of 192.168.1.254.
I have taken two individual devices, though, and assigned
an address reservation.
You can see that 192.168.1.6 is assigned
to a device called Prometheus, and there's
the MAC address of that device.
I also have another server called Odyssey,
and that device with that MAC address
will always receive 192.168.1.9, thanks to this address
reservation configuration.
As we mentioned earlier, the lease
for the IP address that you receive on your workstation
is only available for a certain amount of time,
and unless you renew the lease, you
have to give up that IP address at the end of the leasing
process.
The IP configuration, all of the IP settings, and the lease time
are configured by the DHCP server administrator.
That lease time could be set to be very short,
or the administrator can set it to be days or even
weeks of time.
If a device is rebooted, it does check back
in with the DHCP server, and that lease
may be reconfirmed during that process.
You might also notice in the IP configuration
of a device, that you could manually release the IP
address back to the DHCP server as well,
and then request a new IP address from that server.
This is especially useful if you have a laptop,
you move that laptop to a new subnet,
and you need to have the DHCP process occur again.
You simply release the IP address
that you currently have, and request
the system to renew the IP address with the local DHCP
server.
There are two important timers to know about during the DHCP
leasing process.
The first is a T1 timer.
This is a timer that your client workstation
uses to check back in with the DHCP server
to automatically renew the lease that you currently have.
By default, this is 50% of the lease time.
There's a second timer called a T2 timer.
If the original DHCP server is down or it's unavailable,
the T2 timer will rebind with any available DHCP server.
By default, the T2 timer is 87 and 1/2 of the lease time,
or 7/8 of that available lease time.
Here's how this would work.
Let's say we have a device that's
received a DHCP address the lease time has been configured
on the DHCP server to be 8 days in length.
This means that the T1 timer would occur after four days--
that's 50% of the time--
and the T2 timer would occur after seven days, which
is 87 and 1/2% of the time.
So during the first four days of the lease is normal operation,
and there's no check back to the original DHCP server.
After the first four days have occurred
and that T1 timer is hit, the device
checks back in with the DHCP server to renew the lease,
and the clock starts again on the lease time.
Let's-- say in this scenario, though,
that the original DHCP server is suddenly unavailable--
it's been turned off, or there's been some type of outage--
and we're not able to renew after the T1 timer.
We would wait all the way through to the seventh day--
that is 7/8, or 87 and 1/2% of the time--
to be able to rebind with any other available DHCP server
on the network.
If there is a DHCP server available during this rebinding
process, then we have renewed the lease,
and the timers are reset, and we go
through the exact same process for the renewal
after the T1 timer and the T2 timer.