All language subtitles for 15 - Switching - Cisco Switching - Day to Day-eng

>> You don't have to be in the IT career
field for long to realize that there is a lot

of finger pointing going on in this game.

It's always an IT person's job.

It feels like, to be able to
point a finger somewhere else

that it's not their responsibility.

For example, someone says,
"Hey, the internet is slow."

And, you know, you want to be able to
say, "Well, you know, it's a, you know,

fill in your service right out there."

It's the internet service, right.

They must be, you know, let me call them,
you know, they must be, like it feels good

for an IT person, it shouldn't
be this way, but it is.

It feels good for an IT person to be able to
turn and say, "It's not my fault, it's them."

And let me prepare you as you are
getting into this network world,

you will find that finger pointed at
you so often for issues that well,

it may be your fault, it may be our fault
as network people, but for the most part,

if we do our jobs well, it's not.

It's just-- it's an easy finger to point
when somebody is like, hey, you know what,

things are just running slow, you know, all the
Microsoft team looks over and goes, Cisco guys,

that's their issue, must be them, let's forward
that ticket over to them, it's a slow thing.

So, if things feel slow, it must be a
network thing or programmers, you know.

A lot of times, you know, there
might be a bug in their code.

Not-- it's not always that, you know,
here I am pointing the finger right back.

I'm like, "It's their fault and
it's never our fault," right?

So, programmers often will have
a bug in their code or whatever

and they'll be like, "Oh, it's the network."

And the network guys are like, "No it's not.

Everything works fine except for your
program, I mean, it's your program."

So, you get this big finger pointing game,
that's when I'm about to train you how to do.

[laughs] So, this nugget that you're looking
out right now is actually an after thought.

I was going through and putting
together the flow and I was like, "Okay,

we got the base configuration and I was about
to get into VLANs which is an alter cool topic,

I mean, kind of an earth shattering
topic in terms of network technology.

And I'm sitting here thinking, I'm
like, there's more, there's more.

I felt like there's just more somewhere

in between the base configuration
which we just talked about.

We have our switches manageable
securely and all that kind of stuff.

And then VLANS which is over here.

There's like this squishy middle ground
and that's where this nugget came from.

Day-to-day operation of Cisco switches.

Questions like, "Hey, the network
is slow, what could cause that?"

Or, let me give you a kind of a
more-- a bigger picture to that.

What can you say or what can you do
to prove that it's not the network

or to prove that it is, one of those two.

And that will be some of
the key interface counters.

And then another one will be, you know,
the firewall admin contacts you and says,

"Hey there's somebody with this IP address
that is just flooding our internet connection,

you know, they're causing tons of traffic."

So, they're like, "Where is that person?"

You know, and you go, "Ahh, uhm."

How do you find them, finding
devices using the MAC address table?

So if somebody is point the finger at you saying
you're the problem, your network is the issue,

the best place to go is directly
into the live switch interface

and that's where I want to keep it.

Let's start off with the network is slow.

That is one of the worst
complaints that you can get,

not worst as in it's a major
problem, although it could be.

It's just like, what does that mean?

I mean, it's like saying, somebody come up to me
and like, "My car is broken," and you're like,

"Well, what wrong with your car?"

"I don't know," [laughs] and you're
like, "Ahh, so what's broken about it?"

"Like, I don't know, it's just
kind of doesn't run right."

Well, so you see what I mean?

It's kind of like the network,
so what does that mean?

Like, slow compared to home, are you surfing
the net and you can't watch your YouTube videos?

I mean, what does that mean when you
say the network is slow 'cause it's one

of the most painful things to really even
quantify to say, "Here's what it mean."

So, the biggest thing that we want to look

at when we get network is slow is our interface
counters and as they relate to speed and duplex.

Let me tell you the tale of speed and duplex.

Speed and duplex has long since been an issue.

When you connect a device,
that's a mutant computer,

there to a switch, both sides are set to auto.

And now, I'm drawing a computer but
I'm talking routers, servers, printers,

everything can fall victim to this auto detect.

And what do I mean by auto?

That means that the network card is
designed to auto detect the speed and duplex

to figure out what the other side is.

Are you 10 megabits per second?

Are you a hundred?

Are you gigabit per second?

Are you full duplex to where you can
send and receive at the same time,

you can kind of do this at the same time?

Or, you have duplex to where I can send and you
receive and then I have to wait and you send

and I receive, you know, what are you?

So auto detect is supposed to resolve that.

But there were problems, there
were problems with auto detect

in the 10 megabit per second world, there
was problems with the auto detect mechanism

and the 100 megabit per second world.

They fixed the problems with auto detect
when we got to gigabit per second.

Meaning, it now works in all
the recommendations, well say,

you should set both sides to auto, dot dot dot
if you're running gigabit per-- gigabit speed.

If you got gigabit network cards everywhere
then great, but not everybody will have that

and not everybody will have that for quite
some time because it takes time for things

like gigabit speed to trickle
into all the devices.

We got a lot of-- I mean, I know gigabit
has been out for quite sometime now

but only now are we seeing all the computers
that are mass produced reflecting that.

The IP phones, I mean, you think
about phones and phones affect that,

they plug into the switch and
then they connect to a device.

Well, if you purchase to 150 phones and they're
all 100 megabits per second, then, you know,

upgrading your network to gigabit
just became that much more complex

because you don't just upgrade the
switches and the computers anymore,

now you got to swap out all your phones.

That's a major expense to justify if, you
know, you look at what people use on average.

On average still today, people use maybe eight
megabits per second, no, eight, maybe less,

I would say of speed, I'm referencing
a study I saw some time ago but that--

I mean, that's mostly surfing the web.

I mean, that's people that are
steaming, I mean, just on average

and I'm not talking like
average throughout the day.

Average throughout the day would probably
be like half a megabit per second,

I'm talking like, what's the peak that normal
people use and that's about what it is.

So, with that being said,
gigabit is a long ways off

and so we've got this auto deal to worry about.

Most of the time, auto detect works okay but
when it doesn't, it can cause some major issues.

The speed, I will say, always detects correctly.

So if this side is 100 megabits per second
and this side is 100 megabits per second,

then they will always negotiate
that, that component works fine,

it's the duplex where the issue happens.

One side detects, "Oh, this
is a full duplex connection."

The other side detects, "Oh, no, no, no.

This is half duplex."

Could be the computer, could be the
switch-- I mean, one side missed detect.

So one side thinks it can send and receive at
a time, the other side thinks it can only send

or receive at a time and what
we end up with is collisions.

So collisions are when this side is sending
and this guy is like, "Whoa, whoa, whoa,

I can't receive because I'm sending too,

I'm just going to start dropping
packets because they've collided."

It's how the networks of old used
to work when we had hubs everywhere.

But now that we've moved
into a switch generation,

we should never see any collisions on a port.

What's the result of getting collisions?

Slow, meaning, it's not like the link
just goes down, although it may depending

on how many errors you get on the
line, but usually doesn't just go down.

What happens is you start dropping a bunch of
traffic 'cause it's getting collision saying,

"Oh, well, I-- you sent and I'm
not supposed to be able to receive

that at the same time I'm sending so
I'm drop, drop, drop, drop, drop."

Now, traffic, if it uses TCP which most
applications does, will recover from that.

It's like, "I got dropped, let me slow down a
little bit and resend and resend and resend."

So the result is that we have people that are
just like, "Ahh, just doesn't feel as fast

as it should be," most of the time,
it's a speed and duplex mismatch.

So what does that mean?

What do we do about that?

Well, if we have trouble devices, now it--

I would usually, it doesn't happen with
the computers, it might be a router,

that would be a major trouble
device or a server or,

I don't know, maybe an IP phone or something.

Things that would be major
trouble devices are those kinds

of devices, although computers, they can be.

You can run into computers
that misdetect the duplex.

So what we have to do is hardcode it.

Not hardcode it on one side but
on both sides of the connection.

Because here's another trouble, with 100 megabit
per second, the way the standard is written,

the auto detect standard, is if one side is
hardcoded, let's say I go to this computer

and I say, "Okay, I'm turning
off auto, no auto detect for you

and I'm putting you at 100
megabit per second full."

Full duplex and I connect this to a
switch and I leave this guy as auto.

So one guy is hardcoded, one
guy is auto, what's the result?

Well, the way that the standard is written--

the auto detect standard is if this
guy can't detect what the other side is

and he won't be able to because we've
turned off auto negotiation on this side.

If he can't detect what the other
side is, he's going to resort

to 100 megabits per second half [laughs].

What? Thelma [phonetic], did he say half?

Half duplex every single time because you
have to remember, 100 megabits per second,

that standard was created when it was an error

where half duplex devices were the
norm, they were very common out there.

And what they said when they created the auto
detect standard is they said, "You know what,

if you can't figure it out,
it's safer to default to half

than it is to default to full duplex."

Well, now a days, they fix
that with gigabit per second.

When gigabit came out, everybody is like,
"Well, good grief, who uses half duplex anymore.

Let's make the default full duplex," which
is why the auto detect issues really kind

of started fading away as
gigabit per second came out.

So, the key is if we have
devices, and let me say this, if--

I'm trying to think of a way to put this
into a good rule of thumb to follow.

If you have 100 megabit per second
devices, so, yeah [inaudible].

If we have 100 megabit per second devices

and they are key devices,
hardcoded, what's a key device?

You tell me, what is the key
device, think about in your head?

What it is?

It is a server.

It is a router that a lot of people use.

It is, maybe a surveillance camera for
the security system or I mean, there's--

you have to think about your
environment and think if XYZ went down,

that would cause the major issues.

Those are key devices.

Those are the ones you want to hardcode.

So let's just say we've got a surveillance
camera that watches the lobby all hours

of the day and night, you
know, or something that--

that's a key device where I would go
into the camera itself probably a WebGUI

that would be mounted for that guy.

And I would say this is 100
megabit per second full duplex.

Then I'd go into the switch port and say,
'This is 100 megabits per second full duplex."

Hardcode any key device if it's
in the 100 megabit per second era.

If it's gigabit, use auto.

Keep auto detect turned on because
that usually solves everything

and it's just a lot less work if you do that.

So, okay, we got-- we've got that, we've got
the rules, and now what about end computers?

Should we go to every single computer in our
network and hardcode the computer to be 100,

I mean, if we're using 100
and hardcode the port?

I would say no.

Because computers aren't key devices.

Is there a chance that one of them could
misdetect if both sides are set to auto?

Yes, absolutely, the chance is there but I would
say the success rate on computers is, I mean,

I would-- this is a gutt feeling.

It's probably 95, 98 percent
success on detecting.

So, that 2 to 5 percent that do misdetect

and if this varies different
network cards work differently.

But on those 2 to 5 percent that misdetect,

it's much easier to go troubleshoot
those individually

than hardcode everything
in your entire enterprise.

So here's how you do it.

On the Cisco side, which is
the side you'll want to know,

you go to the interface that
you are concerned about.

Let say-- oh, and I should also mention,
let just say, this interface right here.

Let me also mention-- yeah let's do this one,
that this is not something, if it's a key device

that you would want to do during production
hours, unless it's causing a major issue

and everybody's approved it, because
the port will go down when you do this.

So, essentially network connectivity
lost and it will come back up.

It's usually maybe 5 to 10 second outage.

And you'll like, "Well, 5 seconds, 10
seconds, what's the big deal there?"

Well, depending on the kind of
device that it is, it's a key server,

people are transferring files,
maybe streaming files off of that,

or a router connection where voice over IP.

I mean 5 seconds of audio cutting
out on the voice over IP is deaf.

Nobody has the patience to wait,
they'll go, "Hello, hello, click."

We live in a high speed society.

So, the way that you do this is go under
the interface that you want to hardcode.

And the command is speed and
you type in what the speed is.

Speed 100, it's now hardcoded,
Duplex, and by the way,

if you hardcode one, you have to hardcode both.

So, I'm going to do duplex
full, put that in there.

A thought-- just-- thought just crossed my mind.

You see what's happening, our interface is
going up and down every single time I do this,

so that you can think of that as a mini outage.

But now, that port is hardcoded.

Now, I would go to the other side.

Let's say, FastEthernet0/16
connected to my computer.

You know, that's where I would bust
out the Control Panel, and let's see,

I've got to navigate around in
here, so let's view the status.

Okay, change the adapter settings
on my network, oh, there we go.

I have some-- let's just say, LAN2, go to
the property-- you got to dig for this,

this is why you don't want to
do it on each of the devices.

So you kind of go to the adapter
properties, let's say advance.

We've got connection type,
there we go, connection type.

It's kind of different depending
on the driver for the network card,

but this is where I can come in and say, "Okay,
it's set to auto right now, but I could also,

you know, go a hundred full or a hundred half

and that's how I would hardcode
the other side to match that.

Now, there is another feature that
has come out, it's called Auto MDIX.

Essentially, this feature, it's really cool,

allows the switch to determine what ports
are being use, or let me clarify that,

determine what pins of the network cable
are being used for transmit or receive.

See, there's always been this deal and
we mentioned it early in the series

to where we say, "Okay, well, if you're
connecting a computer to a switch,

we have to use a straight-- a
straight through cable, that's--

sorry, that's totally spelled wrong, you
get it though, straight through cable,

right, to connect dissimilar devices.

Now, if we connect similar devices, like
I connect this switch to this switch

and this switch to this switch,
that's where we use a crossover cable.

And that's, I would say, that's
still a good standard to follow,

but since Auto MDIX came out, which
is probably about five, six years ago,

I mean 2013 right now, so five, six years
ago that this standard was released,

it now can detect-- you can use a
crossover cable to connect to computer.

I can use a straight through cable to connect
switches together, because it will detect it

but Auto MDIX relies on auto negotiation.

So if I go went to a port and type in,
speed auto duplex auto, or wait a second,

speed 100 duplex full, just what I need
right now, then Auto MDIX won't be able

to detect the other side anymore.

So, we have to use the right cable.

So, we can't just use a crossover cable to
connect to PC anymore because it's not going

to be able to detect which pins are being
used, it's all kind of wrapped together

into that big auto detect mechanism.

So, second piece.

The network is slow, how do you-- I mean we
can go in and hardcode the speed in duplex,

but how do you know if you have to.

How do you if there's, you know, if
they really are errors on the line.

Well, that's because-- oh,
shrinking, that's because I can go

in to the interfaces and check the counters.

So, I brought up-- I connected
a few more cables just for this.

I brought up FastEthernet0/16, 0/18, so I can
go in and do a drop, I got show interface,

not show IP interface in
this case, show interface,

and I want to zoom in on FastEhernet 0/18, okay?

First thing I want to look at if
somebody is saying the network is slow,

I'm going to come in there and
say, "Well, what are you set to?

In this case, I can see they are set to
full duplex at 100 megabits per second.

A matter of fact, let me
couple one thing in here.

I'm going to do a show run
interface FastEthernet0/18,

which shows me the configuration, pretty much
nothing underneath that interface right now.

So, I can look and I can go,
"Okay, you are currently set

to full duplex 100 megabits per
second," and that makes me feel good.

So if they're complaining for about slowness,
then I'm going to start coming down here

and say, "Okay, well"-- hang
on, let me cut off that output.

Let me look down at your packet statistics.

Now, I can see, this is actually
my computer right now.

I've got traffic always go into it.

I can see, you know, this is key right
here, full duplex 100 megabits per second.

This is key right here, I see the
interface is up, line protocol is up,

that means it's physically
connected, that's the first stop.

And then line protocol is up,
that means it's communicating.

I drop down and I go, "Okay, well, we've
got queues, if you're getting into routers

and things like that, you would check
your queues because this tells you

if packets are really battling up
like there's not enough bandwidth

to send them, but for now, I mean I'll switch.

You usually don't worry about that,
but this, gives me a lot of good feel.

So I go, "Okay."

Right now, input rate.

So, input, what does that mean?

It means, put yourself in the role of the
switch, you are a switch, ting, designated.

I'm getting right now-- I'm receiving--
somebody is putting into me, as a switch,

142,000 bits per second, so that tells me, 142
kilobits per second in terms of network speed.

And on an output rate, meaning
going-- leaving me, me being a switch,

as in going out FastEthernet0/18
to whatever device that is.

I'm sending looks like a million,
408,000 bits per seconds which is

about 1.4 megabits per second if
I'm looking in terms of bandwidth.

I go, "Okay, well that gives me a feel over
the last 5 minutes of how that's been."

But-- and then goes into some totals.

It says, "Okay, total, we've
had these many packets input."

I've seen these many broadcasts.

And I'm like, "Okay, that's good, that's good.

Okay, packets out, that's good, that's good."

Here's what I'm looking for, right
there, collision and late collision.

Collision means there was
a normal collision online.

Now, if we're in a switch world,
never should you see that, ever,

period, done, [inaudible] end of story.

In a switch environment, there should never be a
collision because full duplex means both sides,

as long-- to their hearts content, they can
send at 100 megabits per second and receive

at 100 megabits per second at the
same, we won't have a collision.

Collision shouldn't happen.

Now, let me do this, I actually
beforehand kind of messed around.

And I tweet my FastEthernet0/16 interface.

Now, I fixed it, you know [inaudible], I put
it, all I did was hardcode it to half duplex

at 100 megabits per second, did
some file transfers because I wanted

to show you, this-- it is showing up.

Now, if you got, you always
got to put this in perspective.

You have to go, "Okay, total, I had 352,000
of that 6,000 work collisions, that would be--

well, I would say, even saying like 10 or
12, the key is, is this continuing to happen?

You'll hit the upper a couple of times.

Take a look, do I continue to
see this counter moving up,

because if I do, it's still a problem.

If not, then it should be okay.

Now, I caused this.

I actually went in and hardcoded it to
be half duplex, but that's something

that immediately will signal us to where--
okay, something is colliding on the other side.

Now, you might be saying, "Okay,
what's up, you got collisions

and then you got late collisions,
what's up with that?"

Difference between those is really
when did the collision happen?

See, there're normal collisions
and then there're late collisions.

Don't you love when you make those
brilliant statements and your like,

"Yeah that was really what
we just saw there, right?"

So, normal collision-- what's the difference.

Normal collision is in the hub
world, you know, if this was a hub,

you've got all the different
devices that are listening, right?

They're all listening to see if they can send,
because only one person can send at a time.

So this guy, you know, he's kind of got this
big old ear, he's listening to the cable

to try and hear if anybody is talking.

Well, this guy has got a
bigger ear, he's listening too.

And the way that the timers work is if
there is a collision that's going to happen,

it's always going to be within
the first 32 bytes of the frame.

So as this guy is starting to send,

a normal collision will always
happen within the first 32 bytes.

Just the way that they engineer the
timers of how they listen, how they sent,

you know that the collision
will always happen there.

A late collision means this guy got,
you know, he's sending, you know,

1,500 byte packet which is as big as
they can be on a normal Ethernet cable.

And somewhere around byte 732, you
know, that he detected data coming

in at the same time he was trying to send,

that means that's beyond the
normal Ethernet standard.

You know, if you're in a hub world in normal
collisions, collisions will happen all the time

in a hub world but it's always going
to happen within the first 32 bytes.

If you go beyond that, it's
considered a late collision.

Late collisions are always
indicative of a duplex mismatch.

I mean, it's like, if you see those taking
up, hands down, you've got a duplex mismatch.

This could happen for instance, if I plug
my switch into a hub and I've got a bunch

of devices on that hub that are all talking.

Then I would expect to see a bunch of normal
collisions, because hubs cause collision.

But in a-- if it's a late collision,

then it's definitely something is
connected and there is a duplex mismatch.

Now, you know, that's a lot of time just
to talk about speed and duplex mismatches,

but it really is a big issue,
it happens commonly,

and it also exposes you to
the interface counters.

So now you have a counter
argument if somebody is like,

"It's the network," and they point at you.

You go, "No, I'm looking here."

Well, not a good example there.

Well, yeah, is it the network
if that's the case.

But, you can look at your
statistics and be like, "No,

I'm seeing packets send, packets receive."

Now, you got to keep in mind that you
want to make sure you trace it end to end.

So, for instance if there saying, "Oh, well,

the connections are slow,"
and you go, "Well, to what?"

They go, "Well, from that host over
there, you know, Joe's [phonetic] computer

over to our server," that where I saw-- you got
to keep eyes right here and say, "Okay, well,

looks like everything is good there," but also
you got to check this link and check this link.

Make sure the whole way through where we don't
have any those collisions or duplex mismatches

or anything like that, because Joe could
just be one victim of a bigger issue

that maybe Joe just happens to be first
one to report, so follow the path.

Now, you also saw when we saw this, you
know, you're able to really get a lot

of those key statistics and compare.

Now, looking at this, there's stuff,
I mean, this output initially,

if you knew the Cisco can be overwhelming.

Its like, "Oh, what is a runt, what's a watch--

, you know, what's a babble,
you know, what does that mean?

I mean, there's a lot under here where
it's like, well what is all of that?

Now, some of them are common, you know, what I
just showed you, you know, knowing collisions,

that's common, knowing packets input and output.

Other-- I mean, if somebody-- I'll tell you
frankly, if somebody walked up to me right now

and they're like, "What's a babble?"

I'd immediately think, my 4-month old kind of,
he's like, [inaudible], like, I wouldn't know,

that I have to look at a reference book.

But if somebody told me, ask
me, "What's a collision?"

Immediately, I'd know the answer.

What's a CRC here?

That's a big one.

CRC, cyclical redundancy check, is
every single frame when you send it,

it's the little piece at the very end of it.

I think we talked about this early on in the
nugget, which makes sure it's a little hash

that is run on that packet before
it's sent that says, "Okay,

I run this all through a big algorithm and if
anything in these changes, by the time it's gets

from point A to point B, the CRC won't match
and it will be considered a bad packet."

So if I see a whole bunch of CRC errors, I'm
going to be like, "Oh, this may be a bad cable,

maybe this cable is going by some
interference like fluorescent lighting,

I've got it wound around a
fluorescent light or, you know,

something that's really causing our data to kind
to get messed up between point A and point B."

So, some of these are going to be key counters.

I have to say that's probably the--
between input and output collisions

and all that, those are the key ones.

The other stuff, I mean, that's
what reference books are made for.

You won't know-- you won't be
asked to quote what a babble is.

So, that kind of leads me into the last piece.

Joe is reporting an issue or someone
is coming to you and saying well,

"Where is Joe in the network,"
or "We're having this IP address,

this is causing a lot of issues."

What I said when I started this whole nugget.

Where are they?

Now, if you're in a big company.

A lot of times, they'll have monitoring
software that kind of pull it all.

You go to web interface and say,
"Where is this MAC address?"

And he's like, [inaudible] and kind just spits
it out, and you go, "Oh, okay, it's over there."

But most people don't have those
kinds of tools at their disposal.

Most people will start something like
this, like let's say they go, "Okay,

well that's 172.30.100.1, you know, and
maybe Joe is, you know, whatever IP address.

Where are they in the network?

The first thing that you're going
to do is open a command prompt

from A device that's on that same network.

And I would say, "Okay, let's
do a ping, 172.30.100.1.

Okay, I'm getting a reply, good,
because that tells me I can get

to that IP address which
means I can do an arp-a.

Oh, what is this?

This gives me the ARP table on my computer.

Remember what ARP is?

Address Resolution Protocol.

When I ping this, my computer has to send
a broadcast to find out what MAC address

that IP address really has, and it's
going to cash that in its ARP table.

So I can do arp-a and hit the enter key,

and see all of the MAC address
that my computer knows about.

And there it is, I go-- okay, right
there, is 172.30.100.1 as well

as 6, as well as 16, as well as 25.

You know, I see all of these IP addresses
that at some point my computer learned

about dynamically on the network
and has added to its ARP table.

So, now, I can go to my switch and
I can say, "Okay, I want to see--

give a show of the MAC address table."

And some versions of the IOS is MAC dash Address
Table, some is MAC Space Address, you know,

just kind of use question
mark to figure that out.

And I can see right here, okay,
I've got all these MAC addresses.

Now, keep in mind in a large network,
this is going to be pure overwhelming.

I mean, you'll have 50 pages of MAC addresses
that have been learned on this device.

So, a lot of times, you know, using
a little filter action is going

to be-- come in really handy.

Well, we're going to say, "Okay, well, I see
the MAC address right here, ends in 01-01,

and I know Cisco doesn't do dashes, they
use periods, so I'll do include 0101.

And now, look at that, it spits out
right there exactly what I'm looking for.

I'll go, "Okay, that MAC address
is located on FastEthernet0/18.

Now, I know you're going like,
"Okay, well, wait a second."

So, what is that?

So, oh it's the same way.

So, what's that, so what's that?

I mean, what's up, is this broken?

How do I have all these MAC
addresses on one port?

I mean I don't get it.

Well, a lot of times, if I've got
switch, you know, this is my environment,

I've got a switch with my computer plugged into
it, and that is up length on FastEthernet0/18

to another switch, and that
goes to another switch

and another switch and so on and so forth.

So, as all the devices that are plugged in
here and here and here communicate, well,

they are all coming in this one interface.

So from my switches perspective right here,
it's learning, you know, MAC address A, B, C, D,

it's learning all of them on that one
interface and that's fine, that's normal.

But what that tells me is, you know, if I'm on
the search, if I'm like, "Okay, it looks like,

you know, I've got to go out, you know,
let's say this is FastEthernet0/18.

I've got to go out that port to find it, and
I see it a ton of MAC addresses on that port

that tells me that's another switch.

So I have to tell that to that switch
and find out what's going on over there,

and we'll get into things later
on like show CDP neighbors

which is actually not running right now.

But that will tell me what the next switch
in line is and I can actually tell that to

that switch and do the same
show command from there.

But, you know, for instance if I was
trying to find my computer, you know,

I know my computer right here is
172.30.100.39 that's my IP address.

Now, it's not going to show up
in the ARP table because it's me.

I don't have to figure out my MAC address.

For me, I do an IPconfig forward slash all
and I would come up here and say, "Well,

let's say I've got-- there's
my MAC address, I use--

the first four digits are sometimes shared,
common between many different devices.

The last four are usually unique, not always
but usually, to where my device will not have

that same last four digits as another.

So, I can come here and do a show MAC address
table and zoom in and say, "Show me 6c32."

And immediately I go, "Okay, great.

This guy has out FastEthernet0/16 and I
can zoom in there and locate that device.

Now, comes the fun part of, "Okay, I know it's
plugged in there, now, where does that go."

And that's where a good documented
physical network layout is good,

and hopefully whatever company did your
cabling, allows you to be able to go, "Okay,

let's run that con-- okay, that
connects to that and that ends up going

out to whatever port that's
located on wall jack 9.

So, finding any device in your network can be
done just through a series of ARP commands.

You know, do an arp-a on your PC, and by the way
even though it's Cisco, Cisco does expect you

to know some of those commands from the
PC like arp-a, like IPconfig, like ping.

It's where you can test the
different devices that way.

If you're on the switch by the
way, the switch can ARP as well.

I can do a show ARP on the switch and
find out what IP addresses it's resolved.

Then you might say, "Well, that's odd.

How come the switch only sees this
one IP address in this ARP table,

but we've got all of the-- I mean won't you
expect to see all those in this ARP table?"

Well, remember the switch is perspective.

The switch is located on the 10.1.1.10 network,
so the only things that it's going to be able

to ARP for are things that are in that subnet.

Now, I'm-- I just-- to do this nugget, I
plugged in a whole bunch of other devices.

I up length this little lab switch to the
rest of my network, so I could get a bunch

of MAC address that's showing up that are on--
we'll call it Jeremy's production network,

but the switch is on that network.

It's, you know, layer two, it may have
those MAC addresses, but at layer 3,

its IP address is not on the same network.

So, it's, you know, it just all of that is
going through the switch, not to the switch.

So the ARP table of the switch is things
that are going to the switch like I want

to communicate with you CBT switch.

All of these other things are just going--
I don't care who you are CBT switch,

I'm going through you to reach whatever
destination I'm trying to get to,

so that's why we see the discrepancy there.

So, we've have seen how we can kind of fight
back if somebody says, the network is slow,

speed and duplex, that's almost always where
that issues is at, or could bad cabling,

look for those CRC errors and things like.

We looked at the key interface counters and
how to locate devices using a series of ARP

and show MAC Address Table Commands.

I hope this has been informative for you
and I'd like to thank you for viewing.