So in this section of the demo we are going to continue
troubleshooting our DHCP server issues,
and this time the configuration at least from the DHCP standpoint is
exactly the same on the Bridge and on the server.
I've not changed any of that, so, nothing up my sleeve there,
but there is still a problem, or I should say still a problem,
but another problem on the client end in that poor Mr.
Client still cannot get an IP address.
Let's verify this first off.
Let's do sh ip int br.
You'll see it as unassigned.
If we do deb dhcp and wait just a second,
we should see that it's trying to get an address,
but it simply cannot.
There's the Broadcast, we never get a response back.
It's broadcasting out, but it still isn't getting anything back.
So we'll un-debug all just so that doesn't take up resources trying to do that.
Just to prove everything is still kosher over on the server,
we'll do here and we'll do sh run s dhcp,
and there we are, Clients 192.
168.
10.
0.
There's the domain and the default router, so this guy's all good.
If we look at the route table on here,
it has a static route going out to there so it knows how to get back,
so we can go over and look on the Bridge and make
sure that everything is working,
so we'll do sh int g0/2 to look at the client side.
So g0/2 is up, line protocol is up, that's the client link,
still got a valid IP address, we're not getting any errors on this.
Okay, g0/1, it's up and up, it's on the right subnet,
we're not getting any errors or anything like that.
So I actually know where the problem is on this guy,
and again,
if you're troubleshooting this kind of problem and
you suspect a network problem,
probably at this point you'd be doing a traffic trace.
So, we can do exactly that inside our virtual infrastructure here.
So, we know the helper address is working here.
Let's look on the Bridge and let's sniff the traffic
going out this interface over here, g0/1 to switch 1,
this link here.
So I'm going to go in to the viral configuration and
set that up and get Wireshark going,
and we'll use the magic of video editing to take us to the
point where all of that is complete.
And now we've done exactly that.
You'll notice that now we have a little magnifying glass here
in our viral console and it shows that we're inspecting the
traffic going out that interface.
And it's loading it over here into Wireshark.
I don't want the software update right now.
And so now we're seeing all the traffic that's leaving that interface,
and we notice that even though the client,
and let's turn on the debug again, the client is actually sending the packet out.
You'll see it's broadcasting it,
but our traffic trace doesn't show that it's actually leaving this router,
and in fact, we get the ICMP message back that says,
destination unreachable, communication administratively filtered.
I love ICMP when you actually look at the packets that come back,
it'll actually tell you exactly what's going on.
In this case,
administratively filtered is a red flag for me that there's
probably an access control list blocking this,
and almost certainly is an access control list.
So, let's go on the Bridge and let's see if there's any access control lists.
So we'll do sh access-lists, and there is indeed an access list 105,
permits tcp any any eq 80 and 443, and permits udp any any eq the bootp client.
So,
this should logically apply to the interface that is pointing at
the client to allow the client traffic in and only also allow 80
and 443 out to the server farm, so you're doing the filtering here at the Bridge.
So let's look at the interface configuration on the Bridge.
Do sh run int g0/2, and we see that it's not actually applying to g0/2,
or it's not actually applied, it's not configured on it.
If we look on g0/1, there is IP access group 105,
and so they've got the wrong interface for the IP access group.
It's essentially limiting the traffic on this segment
where it only allows traffic on 80, 443,
and the bootp client, or DHCP client, inbound on this interface.
Well the client traffic isn't inbound on this interface,
it's inbound on the other interface, so let's swap the interfaces here.
So we'll go to Bridge, do a conf t, int g0/2,
we'll copy this to the other interface, and then remove it from the first,
that way we don't inadvertently let too much traffic through that we shouldn't,
and then go here to 0/1, and just put a no there,
and now we should see some more interesting traffic over here.
There is the DHCP, I've already seen the Discover,
and the Offer, and there's the Transaction.
So if we look over on the client,
we should actually see that it's getting a DHCP Request,
or a Reply here, but it's still not, so let's see.
Make sure that we've got the right interface here.
Sh run int g0/1, and then on g0/2, and if do sh access-lists 105 again,
I know what the problem is actually,
and even though I broke this lab in this particular way,
it didn't actually occur to me how much I had broken
it until just this very moment.
I'm willing to bet you that this access list is filtering out UDP broadcast
traffic because we're not specifically allowing it through.
So let's just do this.
Let's just remove it from GigabitEthernet 0/2,
int g/02, and we will just do no ip access-group 105 in,
write that config, and now I'll bet you the client will actually get an address.
So let's force the issue here.
Int g0/1, do shut, and no shut.
So it changes the state to up, sends out the broadcast,
it got a reply back, and there it is.
It actually allocated IP address 102 this time instead of 101.
Only the DHCP server knows why, but we'll take it.
We now have an IP address there and this time it was a
networking issue instead of a configuration issue. And that my friends closes out our DHCP Troubleshooting.