Wouldn't it be awesome to be able
to predict with accuracy things like sporting events,
or how a network's going to behave?
In previous Nuggets, we're taking a look
at how layer 2 switches learn MAC addresses.
We've also identified how ARP operates,
and also how broadcast operate in a layer 2 environment.
So I thought it would be fun for you
and I in this Nugget to leverage that knowledge
and predict what the MAC address table might
look like on a couple of switches
after specific types of traffic have
been sent over the network.
So here is our topology that we've
used in several other Nuggets.
It consists of two switches that are interconnected
with the trunk, six PCs connected
on access ports on those switches to specific VLANs,
as listed right here.
Also the MAC addresses are right here for each of the devices.
And I just put the last four characters
to make it easier to write out and manage.
I've also got the IP address of the layer 3 logical IP address
information for each host written above that host
as well.
And over here on the left I've got
a couple of tables regarding the MAC address tables
that each of these switches has.
And what we get to do is we are going
to start with clean tables, meaning nothing in those MAC
address tables, and also the PCs with no ARP cache entries.
So we'll clean them all so we're from a fresh starting state.
We'll generate some traffic individually.
And then we'll predict what we expect the MAC address
tables to be on the respective switches.
Also, I want to point out that to build this scenario--
it was not as easy as I had hoped.
Because a normal PC, like a Windows computer or a Linux
box--
they are spitting out frames of data
all the time for lots of different reasons.
So to get this to be a really clean and steady environment,
I'm using six computers here that do nothing until you
ask them to do something.
So there's no chatter in the background
from any of these PCs that might inadvertently
send a frame into the network and skew our MAC address tables
on either of these switches.
So for our first scenario-- and let's go ahead
and just do this one set of traffic,
a ping request from PC-1 over to PC -2, from here to here.
So let's consider this together.
If PC-1 wants to go ahead and ping 10.100.0.2 on that local
network--
if it doesn't know the layer 2 address for PC-2,
PC-1 is going to send out an ARP request that's going
to be a layer 2 broadcast.
And that's going to go into the switch here.
And so at that moment, switch 1 on gig 0/1
is going to learn the MAC address of PC-1.
So its MAC address ending in 6801
is going to be learned on gig 0/1,
and that's an access port that is currently in VLAN 100,
so it'll know that that MAC address is
associated with the VLAN 100.
That ARP broadcast is going to go out to gig 0/2,
and it's also going to be sent out the trunk, which
is going to be received over by switch number 2.
And at that moment right there, switch 2
is going to learn about the layer 2 MAC address of PC-1.
So here on the MAC address table for switch 2,
on switch 2's gig 1/0 interface, it
would have learned about the MAC address of PC-1, which is 6801.
And here's my question.
Does switch 2, over this trunk--
is it going to know what VLAN that frame was associated with?
What do you think?
And if you're saying, oh, yeah, Keith,
we're doing 80.21Q trunking, as we talked about in a previous
Nugget.
And as a result, there'll be a tag indicating
what VLAN that's for.
And you're absolutely right.
And as a result, switch 2 would associate that MAC address
with VLAN 100.
So we have two entries regarding inbound frames on those switch
ports.
And then just to complete the discussion,
that broadcast would be forwarded
out all the other ports associated with VLAN 100,
which would go out here.
So that's our initial broadcast frame from PC-1
and where it goes.
Next we'd want to consider the ARP reply message.
So when PC-2 gets that ARP request,
because it owns the IP address being looked for in that ARP
request, it's going to reply.
And we'll put that response in red.
So the reply is going to go back into the switch.
And at that point, at that moment right there,
switch 1 is going to learn the MAC address of PC-2
on port gig 0/2.
So we have gig 0/2, the MAC address of PC-2,
ending in 6802.
And it's also associated with VLAN 100.
That ARP reply is sent to the specific address
of the requester, which was PC-1.
So the switch, who now knows where the MAC address ending
in 6801 is, would forward that ARP
reply out port gig 0/1 over to PC-1.
And that is just the ARP request and reply.
Next we have the actual ping, the ICMP
ping request and ping responses between PC-1 and PC-2.
And let's use a green color for that.
So the ping request would go from PC-1 into the switch.
The switch already knows about PC-1's MAC address.
And because the layer 2 destination is PC-2,
the switch knows exactly where that host lives,
and it would forward that frame out gig 0/2 to PC-2.
And then the reply to that ping would
go from PC-2 back to PC-1.
So based on all of that traffic, the MAC
address tables on the switches regarding
PCs should look something like this.
There's also some communications that are happening directly
between these two switches, and they also
have MAC addresses on their respective interfaces.
So we might have an additional MAC address from switch 1
that's learned by switch 2 and vice versa.
And those will show up as being an VLAN 1.
We can know that that may happen.
However, our focus for you and I in this exercise
is to take a look at just the MAC addresses regarding
PCs and hosts that these switches are adding
to their MAC address tables.
I am running out of time in this Nugget,
so I'll put some additional scenarios for the other ping
requests in separate individual Nuggets.
And then we can go through them together there.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.