Now we're going to discuss DHCP lease time events.
Now honestly I kind of struggled in what to title this slide or
this section of the course because there's not an easy way to
just kind of sum it up in a few words,
but essentially what happens as you get near the end of your DHCP lease.
For example, if you lease an address for 8 hours,
what happens when that 8 hours is up?
Do you just lose your address?
Do you get a new one?
Do you just drop your connection?
Inquiring minds want to know.
Well, let's find out.
There are 2 timers in DHCPv4 that specify when a workstation
will start asking for another lease for its existing IP
address or for a new IP address.
They are the T1 and the T2 timers.
The T1 timer will expire at 50% of the lease time,
so to go back to our example of an 8-hour lease,
at 4 hours into the lease the T1 timer will expire and then the
client will transition into the renewing state.
The client will then send a new DHCP request to the
server that originally leased its address,
however, unlike the initial DHCP request,
this DHCPREQUEST packet is a unicast packet,
because again,
the client has a valid IP address and it's talking to a known DHCP server
so there's no reason to use broadcast in this scenario.
Now under normal circumstances,
the client will be able to connect to the server and it will say,
hey my T1 timer has expired,
I would like to request this IP address for another 8 hours,
or whatever the lease time happens to be.
DHCP server, again under normal circumstances,
will say, sure absolutely, here's this IP address,
you're welcome to use it for the next lease time,
it goes back into an idle state and the process continues
again and 50% of the new lease time.
However, if it cannot connect to this server,
if it does not get a response back from the initial DHCP server,
it will keep trying unicast packets every so often.
And I say every so often because every DHCP implementation is different,
and again,
I imagine all of these implementations differ also based
upon the amount of time left in the lease.
However, the client will eventually hit the T2 timer.
The T2 timer defaults to 87.
5% of the lease time, or 7/8 of the lease time.
So again, going back to our 8-hour lease,
that's why I picked 8 hours because the math is real easy,
after 7 hours the T2 timer will expire.
When the T2 timer expires the client transitions from the
renewing state into the rebinding state.
At this point, you're getting very close to the lease expiration,
and so the client goes, okay,
I obviously can't connect to my original DHCP server,
I'm going to send a broadcast DHCP request in the hopes that some other
DHCP server that has seen me at some point in the past will respond and let
me know if I can keep this IP address or not.
And again, this is where some of those redundancy situations come into place,
because for this particular DHCP request,
only servers that have seen the client in the past
will respond to this DHCP request.
So again, let's say you have three DHCP servers,
but you've configured it so that only one responds at a given time,
you have a primary and two backups,
obviously those backups will have seen the DHCP client even
though they have not actually leased the address,
and so once it gets to the T2 state, when it's in the rebinding state,
one of those other servers will respond to this broadcast DHCP request message.
If for whatever reason the client still does not get any kind of response,
meaning that you only have a single DHCP server and it happens to be
offline for maintenance when the T2 timer expires,
the lease will actually expire.
And what happens at lease expiration is dependent upon the DHCP implementation.
I've seen some stacks continue to use the IP address even
though the lease is technically expired.
Most DHCP implementations will simply drop the IP address
and you'll end up with one of those 169.
254 automatic IP addresses like you see in Windows.
Regardless, according the RFC what's supposed to happen is the lease will expire,
you'll drop the IP address, and you'll then transition to the INIT state,
and essentially start the entire lease process from scratch,
sending those broadcast packets to any DHCP server that
happens to be out there whether or not it's actually seen
this client at some point in the past.
So obviously, DHCP has been around for quite a while.
That's why there's all this robustness built into the protocol,
and again, these values that you see on the screen here are the defaults,
the T1 defaults to 50%, the T2 defaults to 87.
5%.
These values can be changed using DHCP options if you so desire.
Again,
I've never seen an implementation where you change the T1
and T2 values because they're generally accepted values
that are used the world over, but you can change them if you want. We'll talk about DHCP options here in just a moment.