- [Instructor] At this point in your training,
you should already be familiar with the theory
and operation of DHCP.
For the NRC exam specifically,
you need to be able to troubleshoot DHCP.
We'll start by taking a look first at troubleshooting DHCP
from the client side of things.
Here I have a windows-based client,
and if we want to see addressing information,
we can open a command line as I have here,
and we can run the command IP config.
Here, we can see that output stating the IP address.
10.32.1.67.
We can also see the sub-net mask, 255.255.0.0,
and we can see the default gateway, 10.32.0.203.
So, these are the settings in my virtualized host.
If we're using DHCP to assign these addresses,
which is very common for our clients
in an enterprise network, the client is going
to obtain all of this information automatically
from a DHCP server on the network.
When we're looking at an IPv4 address,
we have two parts.
We have the network portion or the subnet portion,
and we have the host portion.
The host portion is the actual IP address for the device
that we're examining
and the network or subnet portion determines
what other devices can communicate with the host.
If devices don't share the same subnet,
this can cause issues with layer two frame addressing.
Here, we can see an example of two PCs
on the 192.168.1.0/26 network.
PC one is at 192.168.1.10
and PC two is at 192.168.1.20.
Both are using a slash 26 subnet mask,
which is 255.255.255.192.
So, the range of possible IP addresses in this network,
would be 192.168.1.1 through 1.62.
And that means that these hosts do in fact reside
on the same subnet.
So, when PC one attempts to communicate with PC two,
PC one will use the address resolution protocol or AARP
to determine the IP address of PC two,
in order to decide if it resides on the same subnet.
We can see these hosts are connected into router one,
and that is actually the default gateway
of 192.168.1.1.
Because these hosts reside on the same subnet,
PC one will determine that it can communicate directly
with PC two, rather than using the default gateway.
PC one would create a frame with its own Mac address as
the source and the Mac address of PC two would be
the destination.
However, what if PC one wanted to communicate with
the web server that we see on the other side,
which has an IP address of 10.1.1.50.
Well, this server very obviously is not on the same sub-net.
So, when PC one uses AARP to resolve the servers addressing,
it's going to recognize that, and it knows that
the default gateway must be used for communication.
Therefore, the destination Mac address for any frame created
by PC one, that's destined to the server is going to be
the Mac address of the default gateway,
which is the router in this case, rather than
the Mac address of the server itself.
Let's alter this example just a bit.
And here you can see everything is exactly the same,
except for the fact
that we have misconfigured PC two's sub-net mask.
In this case, that's configured as 255.255.255.240
or a slash 28.
If PC one, again, tries to communicate with PC two,
this time PC one will determine that PC two is not on
the same sub-net even though they actually are.
Therefore, instead of communicating directly,
it's going to send frames to the default gateway,
which is again, our router,
so that they are then routed to PC two.
This can cause potential communication issues
when we have a mismatch like this.
If the netmask is wider than it should be,
hosts within the same subnet can still communicate
because you're actually allowing more addressing
than desired.
However, this can prevent communication
with some of those unexpected hosts because
an AARP resolution may fail
since they are physically outside of the subnet.
If the netmask is too narrow,
we have the opposite take place.
Communication between legitimate hosts within
the subnets can be affected because the host thinks
the default gateway should be used for communication,
which we just saw in our previous example.
Communication may still take place depending on
how your network is configured, if you have proxy AARP,
for example, but generally speaking,
this is an issue you would want to correct
to avoid any potential problems.
These principles of course also apply
to IPV6 networks as well.
So again, with a DHCP client,
if we're having communication issues,
make sure first that you have an address assigned
to the host.
This validates that DHCP communication is taking place.
If not, if you see an APIPA address starting with 169,
then there was a problem with the host being able to obtain
a valid IP address from the DHCP server.
This could also point to issues within the network
at layer two as well.
Things like spanning tree or VLN assignments and trunks,
which would prevent the DHCP messages from moving between
the client and the DHCP server.
We'll discuss this a bit more in our next video.
From the host perspective, if the host has a valid address,
double-check the assigned a default gateway and subnet mask
to make sure they are correct.
If you have any doubts about the assignment,
you can always try manually configuring everything
on the host adapter to see if
that corrects any communication issues.
And of course,
we don't want to forget physical troubleshooting.
This can include failed or disabled network ports,
and of course, faulty wall jacks or copper cables.
In our next video, we want to dive into
how we can troubleshoot potential DHCP issues
from the perspective of Cisco iOS.