Original subtitles

>> 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.