So now we're going to move on and talk about troubleshooting DHCP,
because after all,
as network administrators administrators and network engineers,
that's what we're here for,
we're here to troubleshoot problems and find solutions.
To be honest, troubleshooting DHCP is not really all that difficult,
he says ducking the eggs and rotten tomatoes that are being thrown at him from
the people that have had to troubleshoot DHCP in the past.
But really, when it comes right down to it,
DHCP is a pretty simple protocol and the failures can be
categorized into two overarching categories,
connectivity or communications, and DHCP server configuration.
And yes,
that's probably a gross over-simplification that could probably
apply to most everything in the networking realm.
Well, it's either connectivity or configuration.
But honestly,
DHCP is one of those core networking protocols that
pretty much is hard to break.
In fact, as we go through this module,
we have some broken configurations in our Cisco lab,
and it honestly took me quite a bit of time to figure how to break
DHCP because a lot of the times it just works,
if you do your due diligence.
Ensure your firewalls allow UDP traffic on the specified ports for DHCPv4,
DHCPv6,
and that you're allowing broadcast and/or multicast
traffic through the firewall.
Now honestly,
this is more of a consideration on the server side than it is the client
side because most firewalls allow outbound traffic,
but if you have a DHCP server running and you forget
to turn off the Windows Firewall,
or allow a firewall exception in Windows Firewall as an example,
then your DHCP server will fail to respond.
Next, check the network cabling for loops.
If a DHCP server receives the same DHCP request multiple times,
then one of those DHCP requests will get a DHCP NAK,
or Negative Acknowledgment, saying hey, I've already got this request,
I'm turning down this request.
And if that NAK gets back to the client,
then the client will simply say, oh well,
I can't talk to that DHCP server, I'm going to try something else.
It won't ever actually make the request to the DHCP server.
Now this is not as much of a problem in modern networks as it was say
8 or 9 years ago before managed switches and spanning tree at the
edge of the network was just ubiquitous,
back when you had hubs that didn't really have much intelligence in them.
This was more of a problem if you didn't keep your wiring
closets clean enough to trace cables,
or if you had a user that just connected two ports in the
same office on the other end of the line.
But if you have an older network with hubs in them
and you have a loop in the network,
you could get duplicated traffic to the DHCP server and the client,
and that will cause connectivity problems.
Also, if you have a network that is changing a lot,
and spanning tree is constantly re-computing and bringing links up and down,
that can cause too much of a delay between the time the DHCP
request is sent and the time the operating system needs an IP
address to continue booting, and you'll end up with no IP address.
The packet will time out before it actually gets back to the workstation.
And you've seen this on Windows workstations especially.
If it can't contact a DHCP server, you'll come up with that lovely 169.
254.
whatever address.
Now,
unfortunately in our DHCP lab because it's all virtual it's very
hard for me to introduce a loop or introduce any stability issues
into the configuration because again,
the logic inside the virtual lab just doesn't really let that happen easily.
And lastly, if you're using ACLs, or access control lists,
on your routers or switches, check those access control lists.
So many people build ACLs and they only inspect TCP traffic
and they only allow TCP traffic as a result,
and once again, we have to say, what protocol does DHCP use?
Say it with me everyone, it uses UDP.
So if you're not specifically allowing UDP traffic and specifically allowing
UDP on the ports that the DHCP server and clients use,
then you're going to have a bad time.
Also, if your ACLs are filtering out broadcast or multicast traffic,
again, a lot of people just block multicast traffic at the source,
or rather at the edge of the network which is the
source for us networking types I guess,
and then if they happen to use IPv6 or DHCPv6,
they're mystified as to why their DHCP server doesn't function properly.
So again, just as a bit of a review, check the configurations,
check the network cabling for loops,
check that you're allowing the traffic to get back and forth,
and if you do all of that, you're almost certainly going to have a functioning DHCP environment.