WEBVTT

0:00:07.520000 --> 0:00:09.320000
 Let's start. Physical layer.

0:00:09.320000 --> 0:00:12.080000
 Let's check the physical layer
 on your router or your switch.

0:00:12.080000 --> 0:00:15.300000
 First thing to ask, yes, we're right
 back to this again, is the router

0:00:15.300000 --> 0:00:17.280000
 a switch turned on?

0:00:17.280000 --> 0:00:19.200000
 Hopefully it is.

0:00:19.200000 --> 0:00:20.580000
 Let's assume it is.

0:00:20.580000 --> 0:00:25.400000
 Okay. Next. Physical layer.

0:00:25.400000 --> 0:00:28.040000
 Maybe the ethernet cable isn't
 pushed in all the way.

0:00:28.040000 --> 0:00:29.140000
 Maybe it has a broken clip.

0:00:29.140000 --> 0:00:30.880000
 This is a very common problem.

0:00:30.880000 --> 0:00:33.500000
 Those little safety clips are on the
 end of those ethernet cables are

0:00:33.500000 --> 0:00:35.240000
 extremely fragile.

0:00:35.240000 --> 0:00:38.240000
 Those things get broken
 off all the time.

0:00:38.240000 --> 0:00:42.560000
 And the result of that is if you plug
 in an ethernet cable into an RJ45

0:00:42.560000 --> 0:00:45.880000
 jack and it doesn't have that clip, it's
 very easy for that thing to just

0:00:45.880000 --> 0:00:49.180000
 slip right out. There's nothing that's
 holding it nice and snug in there.

0:00:49.180000 --> 0:00:52.320000
 So maybe it looks like it's in, but
 it's not actually pushed in all the

0:00:52.320000 --> 0:00:57.140000
 way and the pins aren't making electrical
 connectivity with the RJ45 connector

0:00:57.140000 --> 0:00:58.880000
 in the router or the switch.

0:00:58.880000 --> 0:01:00.200000
 So try that out.

0:01:00.200000 --> 0:01:01.900000
 Maybe swap the cable.

0:01:01.900000 --> 0:01:04.260000
 Once again, wrong cable type.

0:01:04.260000 --> 0:01:07.100000
 We already talked about this,
 but you'll want to check that.

0:01:07.100000 --> 0:01:10.180000
 Are we dealing with a crossover
 straight through cable?

0:01:10.180000 --> 0:01:13.440000
 Next physical layer issue.

0:01:13.440000 --> 0:01:17.080000
 If you're dealing with a router, a
 switch that has removable modules.

0:01:17.080000 --> 0:01:20.120000
 So for example, here's
 a removable module.

0:01:20.120000 --> 0:01:23.660000
 This one is an eight
 port serial module.

0:01:23.660000 --> 0:01:26.520000
 Well, if you turn that thing around and
 you look at the back of it, every

0:01:26.520000 --> 0:01:31.060000
 module will have some sort of pins
 or connectors so that when you plug

0:01:31.060000 --> 0:01:35.140000
 it into the slot, it can connect to the
 pins on the chassis or the backplane

0:01:35.140000 --> 0:01:38.860000
 of the chassis. Another problem that
 sometimes people have is they just

0:01:38.860000 --> 0:01:41.600000
 didn't quite push in that
 module all the way.

0:01:41.600000 --> 0:01:45.400000
 It looks like it's in, but if you actually
 push a little bit harder, now

0:01:45.400000 --> 0:01:46.820000
 all the lights come on.

0:01:46.820000 --> 0:01:49.160000
 So it's possible the module is just
 a little bit loose and needs to be

0:01:49.160000 --> 0:01:51.280000
 firmly seated in the chassis.

0:01:51.280000 --> 0:01:55.720000
 So check that. Let's say you
 rule out those issues.

0:01:55.720000 --> 0:02:01.500000
 Okay. On Cisco routers and Cisco switches,
 interfaces can be what's called

0:02:01.500000 --> 0:02:03.500000
 administratively disabled.

0:02:03.500000 --> 0:02:08.080000
 That means that using a Cisco iOS command,
 somebody shut down the interface.

0:02:08.080000 --> 0:02:10.960000
 So even something's plugged into
 it, that interface is dead.

0:02:10.960000 --> 0:02:12.800000
 It's not talking to anybody.

0:02:12.800000 --> 0:02:16.340000
 Now router interfaces, like it says right
 here, are administratively disabled

0:02:16.340000 --> 0:02:21.140000
 by default. So what you'll want to
 check for that is use that command.

0:02:21.140000 --> 0:02:26.300000
 We just talked about show IP interface
 brief right there and look to see

0:02:26.300000 --> 0:02:28.460000
 if it says administratively down.

0:02:28.460000 --> 0:02:33.400000
 If that's the issue, real quick fix on
 that once you're in privilege exec

0:02:33.400000 --> 0:02:36.240000
 mode, type in configure terminal.

0:02:36.240000 --> 0:02:40.020000
 That's your first step to configuring
 or changing the configuration of

0:02:40.020000 --> 0:02:45.320000
 the device. Then type in the type in
 the word interface and the interface

0:02:45.320000 --> 0:02:46.620000
 that you're trying to fix.

0:02:46.620000 --> 0:02:51.740000
 And once you're in that interface, the
 command you want is no shutdown.

0:02:51.740000 --> 0:02:55.040000
 No shutdown will bring
 that interface up.

0:02:55.040000 --> 0:02:59.720000
 Now Cisco switches, sometimes there
 are protocols or features that run

0:02:59.720000 --> 0:03:03.460000
 on Cisco switches that can cause their
 interfaces to go into what's called

0:03:03.460000 --> 0:03:07.240000
 the air disabled state, where the protocol
 or feature detects something

0:03:07.240000 --> 0:03:10.200000
 that happened that it didn't like.


0:03:10.200000 --> 0:03:14.680000
 And so once again, if you do the command
 show interface, you might see

0:03:14.680000 --> 0:03:17.440000
 that says air disabled.

0:03:17.440000 --> 0:03:24.300000
 Also, now if you see that, there's about
 15 or 20 different things that

0:03:24.300000 --> 0:03:27.000000
 could cause an interface
 to go air disabled.

0:03:27.000000 --> 0:03:31.460000
 Now air disabled technically is
 not a physical layer problem.

0:03:31.460000 --> 0:03:36.220000
 And what I mean by that is whatever the
 root cause was, whatever the issue

0:03:36.220000 --> 0:03:40.000000
 was that caused it to go air disabled,
 that was not something at the physical

0:03:40.000000 --> 0:03:44.240000
 layer. That was something at layer
 two or higher that caused this.

0:03:44.240000 --> 0:03:47.760000
 But the reason I have this in the physical
 layer section is because once

0:03:47.760000 --> 0:03:52.720000
 an interface becomes air disabled
 at the physical layer, it's down.

0:03:52.720000 --> 0:03:55.020000
 It's not doing anything.

0:03:55.020000 --> 0:03:58.680000
 So your next logical question might
 be, okay, well, what caused it to

0:03:58.680000 --> 0:04:00.220000
 go air disabled?

0:04:00.220000 --> 0:04:03.840000
 Vast majority of features that will
 put an interface in the air disabled

0:04:03.840000 --> 0:04:08.500000
 state will log a reason
 as to why they did that.

0:04:08.500000 --> 0:04:12.860000
 And if it's still in the log, if it
 hasn't been overwritten, you might

0:04:12.860000 --> 0:04:14.020000
 be able to see it.

0:04:14.020000 --> 0:04:15.780000
 So you could do the
 command right here.

0:04:15.780000 --> 0:04:19.700000
 Now, if you just do the command show
 logging and you hit enter, you'll

0:04:19.700000 --> 0:04:20.920000
 see the entire log.

0:04:20.920000 --> 0:04:26.020000
 And I think by default, the log stores like
 up to about 500 lines of information.

0:04:26.020000 --> 0:04:30.160000
 And then once it reaches that, it just
 starts erasing old log messages

0:04:30.160000 --> 0:04:32.440000
 to make room for new log messages.


0:04:32.440000 --> 0:04:35.740000
 So if you do show logging,
 you'll see everything.

0:04:35.740000 --> 0:04:38.200000
 But it's probably going to be way too
 much stuff in there for you to wade

0:04:38.200000 --> 0:04:43.560000
 through. So if you do show logging and
 then you use the pipe symbol and

0:04:43.560000 --> 0:04:48.340000
 use the word and use the letter I for
 include and then say include air

0:04:48.340000 --> 0:04:53.960000
 disabled, that will only show you log
 messages that include the word air

0:04:53.960000 --> 0:04:57.480000
 disabled. Like in this particular case,
 out of all the log messages, it

0:04:57.480000 --> 0:05:01.360000
 shows me this one and tells me, ah,
 okay, there's some feature called

0:05:01.360000 --> 0:05:06.280000
 BPU guard, which caused this interface
 to become air disabled.

0:05:06.280000 --> 0:05:11.280000
 Now, like I said, if you see that, you're
 lucky because that system log

0:05:11.280000 --> 0:05:15.600000
 gets overwritten fairly quickly, depending
 on how many sys log messages

0:05:15.600000 --> 0:05:17.780000
 are going on at any given time.

0:05:17.780000 --> 0:05:19.860000
 So you might see nothing.

0:05:19.860000 --> 0:05:22.460000
 Another physical layer issue.

0:05:22.460000 --> 0:05:27.200000
 If you're using fiber optic cables with
 fiber optics, like I said in some

0:05:27.200000 --> 0:05:31.680000
 of the pre in the previous video, you got
 one fiber optic strand for transmit,

0:05:31.680000 --> 0:05:34.160000
 another fiber optic
 strand for receive.

0:05:34.160000 --> 0:05:37.800000
 Now, most of the time, those two cables
 are actually bundled together.

0:05:37.800000 --> 0:05:41.420000
 So you might have two separate connectors,
 but they're bundled together

0:05:41.420000 --> 0:05:44.660000
 into one cable. But that's
 not always the case.

0:05:44.660000 --> 0:05:48.460000
 Like for example, right here, I just
 have a single cable on the left,

0:05:48.460000 --> 0:05:52.220000
 which is it could be used for transmit,
 could be used for receive.

0:05:52.220000 --> 0:05:55.760000
 And something I hear a lot, well, not
 a lot, but a common issue I hear

0:05:55.760000 --> 0:05:59.420000
 from people that have a lot of fiber
 optic cables is they connect those

0:05:59.420000 --> 0:06:04.140000
 cables back to a central place called
 a patch panel, a fiber optic patch

0:06:04.140000 --> 0:06:08.480000
 panel. And it's possible that by doing
 the patch panel here, you've done

0:06:08.480000 --> 0:06:11.660000
 it wrong. You plugged it into a port
 in the patch panel and the other

0:06:11.660000 --> 0:06:14.320000
 side of that patch panel
 has nothing connected.

0:06:14.320000 --> 0:06:17.900000
 Your fiber optic cables basically plug
 into something that isn't connected

0:06:17.900000 --> 0:06:19.920000
 all the way through
 to the other end.

0:06:19.920000 --> 0:06:25.200000
 Or even worse, the transmit of your fiber
 optic is plugged into the patch

0:06:25.200000 --> 0:06:29.120000
 panel, which is going to the
 receive of device number one.

0:06:29.120000 --> 0:06:34.160000
 Now I would expect that the transmit
 of device number one would come back

0:06:34.160000 --> 0:06:36.820000
 to the receive of my device.

0:06:36.820000 --> 0:06:39.480000
 But with a patch panel, especially with
 cables like this, it's possible

0:06:39.480000 --> 0:06:46.760000
 that the transmit strand is going to
 one device, but my receive fiber

0:06:46.760000 --> 0:06:51.100000
 is coming from a completely different
 device because I miscabled it, I

0:06:51.100000 --> 0:06:56.760000
 screwed it up. So that would be considered
 a physical layer issue.

0:06:56.760000 --> 0:07:00.040000
 And of course, Ethernet speed.

0:07:00.040000 --> 0:07:05.400000
 Now I mentioned that with duplex, if
 you had half duplex on one side and

0:07:05.400000 --> 0:07:09.820000
 full duplex on the other, you could
 theoretically get data through.

0:07:09.820000 --> 0:07:13.620000
 It just really depends on the full
 duplex side, how much talking he's

0:07:13.620000 --> 0:07:17.880000
 doing. If he's talking a lot, that could
 make the half duplex side almost

0:07:17.880000 --> 0:07:18.880000
 impossible to talk.

0:07:18.880000 --> 0:07:23.920000
 But it just depends on the rate of data
 that the full duplex side is sending.

0:07:23.920000 --> 0:07:28.540000
 With speed, if there's a speed mismatch,
 you're dead in the water.

0:07:28.540000 --> 0:07:32.120000
 If I have one side that's 10 megabits
 per second and another side that's

0:07:32.120000 --> 0:07:36.040000
 100 megabits per second, they're not
 even talking at the same rate.

0:07:36.040000 --> 0:07:40.460000
 They can't even sample the ones and zeroes
 off the wire at the same time.

0:07:40.460000 --> 0:07:44.200000
 There's no way you're going to get
 anything through on that wire.

0:07:44.200000 --> 0:07:48.100000
 Now, hopefully, like I mentioned before,
 you've got auto negotiation on

0:07:48.100000 --> 0:07:51.480000
 both sides, so speed should
 not be an issue.

0:07:51.480000 --> 0:07:55.180000
 It's only going to be an issue of somebody
 hard coded it and they did

0:07:55.180000 --> 0:07:58.580000
 it wrong. And in this case, they'd have
 to hard code it on both ends of

0:07:58.580000 --> 0:08:02.440000
 the cable. They'd have to hard code
 one speed and a different speed on

0:08:02.440000 --> 0:08:06.560000
 the same cable. Like for example, here,
 here in this output, we can see

0:08:06.560000 --> 0:08:11.460000
 on this interface, it says
 it's down, not connect.

0:08:11.460000 --> 0:08:16.600000
 Okay. Now, it does give us a speed,
 but we don't know from the output

0:08:16.600000 --> 0:08:20.920000
 of this particular command if that
 speed was manually configured with

0:08:20.920000 --> 0:08:25.100000
 an iOS command or if it just
 automatically derived that.

0:08:25.100000 --> 0:08:29.520000
 Because after all, it does say auto duplex,
 so that could lead me to believe

0:08:29.520000 --> 0:08:32.420000
 that, well, maybe that's
 an auto negotiated speed.

0:08:32.420000 --> 0:08:36.760000
 So the output of this command doesn't
 really help me determine if we have

0:08:36.760000 --> 0:08:38.220000
 a speed mismatch.

0:08:38.220000 --> 0:08:40.800000
 So I have to dig a
 little bit deeper.

0:08:40.800000 --> 0:08:46.240000
 So for that, you're going to want to
 do the command show interface status.

0:08:46.240000 --> 0:08:48.660000
 Now, notice here it says connected,
 but the main thing I want to point

0:08:48.660000 --> 0:08:51.860000
 out is it says A-100.

0:08:51.860000 --> 0:08:57.860000
 That means my speed is 100 megabits per
 second and it was auto negotiated.

0:08:57.860000 --> 0:09:00.040000
 Okay. Let's contrast that.

0:09:00.040000 --> 0:09:02.200000
 Look at this output right here.

0:09:02.200000 --> 0:09:04.520000
 It says not connect.

0:09:04.520000 --> 0:09:06.220000
 Look what's missing.

0:09:06.220000 --> 0:09:08.080000
 I'm missing the A in front of 100.


0:09:08.080000 --> 0:09:11.160000
 That means that speed
 has been manually set.

0:09:11.160000 --> 0:09:16.380000
 And sure enough, if I do my show run
 command and I look at that interface,

0:09:16.380000 --> 0:09:18.180000
 I can see speed right there.

0:09:18.180000 --> 0:09:21.780000
 Somebody manually set the speed
 and they did it wrong.

0:09:21.780000 --> 0:09:26.000000
 The other side presumably is 10 megabits
 per second and so there's a speed

0:09:26.000000 --> 0:09:31.880000
 mismatch. So that's your basic
 physical layer issues.

0:09:31.880000 --> 0:09:36.140000
 Now, as far as data link layer stuff,
 not a lot that we can troubleshoot

0:09:36.140000 --> 0:09:39.460000
 the data link layer on our
 routers and switches.

0:09:39.460000 --> 0:09:42.200000
 So let's talk about
 what might be wrong.

0:09:42.200000 --> 0:09:47.960000
 So let's start with
 PPP over Ethernet.

0:09:47.960000 --> 0:09:53.460000
 So as far as just regular Ethernet is
 concerned, I'll get to that in just

0:09:53.460000 --> 0:09:58.320000
 a second, but at the data link layer
 on just a regular Ethernet interface,

0:09:58.320000 --> 0:10:03.540000
 on a switch connected to a PC or laptop,
 not a lot that can be wrong there.

0:10:03.540000 --> 0:10:06.760000
 Hardly anything that
 I could think of.

0:10:06.760000 --> 0:10:11.860000
 But PPP over Ethernet, a lot of companies
 have a fiber optic connection

0:10:11.860000 --> 0:10:16.080000
 coming into their company and that's what
 they use for internet connectivity.

0:10:16.080000 --> 0:10:20.740000
 And on that fiber optic connection,
 they're sending Ethernet frames and

0:10:20.740000 --> 0:10:23.820000
 they inside those Ethernet
 frames they're running PPP.

0:10:23.820000 --> 0:10:28.040000
 Now if you remember from some of the
 previous videos, PPP and Ethernet

0:10:28.040000 --> 0:10:32.460000
 are two completely different
 layer two protocols.

0:10:32.460000 --> 0:10:35.800000
 PPP was actually developed back in the
 days of dial up when you do dial

0:10:35.800000 --> 0:10:39.680000
 up networking and using your modem you
 would call America Online or something

0:10:39.680000 --> 0:10:43.300000
 like that. And then over that modem
 connection you'd use the point to

0:10:43.300000 --> 0:10:45.220000
 point protocol, PPP.

0:10:45.220000 --> 0:10:50.840000
 But over a decade ago, people realized
 that, hey, if we have this fiber

0:10:50.840000 --> 0:10:55.720000
 optic ring that runs for several miles
 in our city and we got different

0:10:55.720000 --> 0:10:58.200000
 buildings tapped into
 that fiber optic ring.

0:10:58.200000 --> 0:11:02.860000
 And one of the things that's tapped
 into that ring is an ISP switch.

0:11:02.860000 --> 0:11:07.520000
 Well, the ISP doesn't want just anybody
 who's willy-milly tapped into

0:11:07.520000 --> 0:11:10.420000
 that ring getting free
 internet connectivity.

0:11:10.420000 --> 0:11:14.400000
 They want to be able to track who's
 on that ring and who's connected and

0:11:14.400000 --> 0:11:17.600000
 only authorized users are actually allowed
 to get internet connectivity

0:11:17.600000 --> 0:11:20.080000
 and those authorized
 users are billed.

0:11:20.080000 --> 0:11:22.060000
 Well, how can we tell
 who's authorized?

0:11:22.060000 --> 0:11:25.520000
 Because if you think about an Ethernet
 frame inside of an Ethernet frame,

0:11:25.520000 --> 0:11:29.500000
 there's no field that says, here's
 my password, here's who I am.

0:11:29.500000 --> 0:11:31.140000
 Ethernet doesn't do that.

0:11:31.140000 --> 0:11:35.520000
 But PPP does. PPP you
 can do authentication.

0:11:35.520000 --> 0:11:38.320000
 So several years ago people said,
 hey, why don't we do this?

0:11:38.320000 --> 0:11:40.740000
 Why don't we have
 an Ethernet frame?

0:11:40.740000 --> 0:11:43.420000
 And inside that Ethernet
 frame, do PPP.

0:11:43.420000 --> 0:11:47.140000
 So we can take advantage of PPP's
 authentication mechanisms.

0:11:47.140000 --> 0:11:50.480000
 Well, that is a potential problem area
 because now if that authentication

0:11:50.480000 --> 0:11:54.980000
 is not working, if that authentication
 is wrong, if you typed in the wrong

0:11:54.980000 --> 0:11:59.000000
 username or the wrong password, your
 PPP over Ethernet authentication

0:11:59.000000 --> 0:12:04.640000
 will fail. And that is technically a
 layer two or a data link layer issue.

0:12:04.640000 --> 0:12:07.420000
 So how would we check that?

0:12:07.420000 --> 0:12:09.980000
 Well, first of all, what would be your
 sort of your indicators that that

0:12:09.980000 --> 0:12:11.480000
 might be the issue?

0:12:11.480000 --> 0:12:15.240000
 Well, on your router or your switch
 that's doing PPP over Ethernet, you

0:12:15.240000 --> 0:12:21.640000
 might see syslogs that look something
 like this, where an interface is

0:12:21.640000 --> 0:12:26.560000
 bound to a dialer interface or
 a virtual access interface.

0:12:26.560000 --> 0:12:31.500000
 And you're seeing that interface
 saying up and down, up and down.

0:12:31.500000 --> 0:12:36.440000
 So anytime you're looking at a dialer
 interface, if you're not doing modems

0:12:36.440000 --> 0:12:41.140000
 and you're not doing ISDN, which you're
 probably not, that's probably

0:12:41.140000 --> 0:12:43.360000
 something to do with
 PPP over Ethernet.

0:12:43.360000 --> 0:12:47.400000
 So that dialer interface going up, down,
 up, down, up, down is indicating

0:12:47.400000 --> 0:12:50.560000
 that, okay, something is
 going wrong with PPP.

0:12:50.560000 --> 0:12:55.460000
 It's not happy. Another way, as you
 say, okay, well, according to this,

0:12:55.460000 --> 0:13:01.040000
 this interface is really, it's virtual
 access one that's going up and

0:13:01.040000 --> 0:13:01.960000
 down, up and down.

0:13:01.960000 --> 0:13:03.880000
 So let me take a look
 at that interface.

0:13:03.880000 --> 0:13:08.060000
 Now you might have no idea what
 a virtual access interface is.

0:13:08.060000 --> 0:13:09.220000
 You don't have to know.

0:13:09.220000 --> 0:13:11.900000
 What you do have to know is, hey, that
 is the interface that's bouncing,

0:13:11.900000 --> 0:13:13.020000
 going up and down.

0:13:13.020000 --> 0:13:15.860000
 So let's take a look at it.

0:13:15.860000 --> 0:13:19.780000
 So we can do show interface
 virtual dash access one.

0:13:19.780000 --> 0:13:22.180000
 It says line protocol is down.

0:13:22.180000 --> 0:13:24.380000
 And here's the key thing.

0:13:24.380000 --> 0:13:29.720000
 LCP is closed. Now I'm not going to
 get into a lot of details of how PPP

0:13:29.720000 --> 0:13:35.940000
 works. But one of the things PPP does
 is when a PPP session is very first

0:13:35.940000 --> 0:13:39.760000
 brought up, PPP has to go through
 some negotiations first.

0:13:39.760000 --> 0:13:40.840000
 It's not like Ethernet.

0:13:40.840000 --> 0:13:45.100000
 With Ethernet, I just take my data,
 wrap it inside an Ethernet frame,

0:13:45.100000 --> 0:13:46.780000
 send it on the wire.

0:13:46.780000 --> 0:13:48.200000
 PPP is not like that.

0:13:48.200000 --> 0:13:51.700000
 PPP says, hey, I need to first
 negotiate some parameters.

0:13:51.700000 --> 0:13:55.660000
 Make sure that you and I can
 do the same types of things.

0:13:55.660000 --> 0:13:59.020000
 Negotiate authentication if
 we're going to do that.

0:13:59.020000 --> 0:14:01.340000
 Make sure our passwords and patch.


0:14:01.340000 --> 0:14:05.000000
 And then if that's okay, then I'll
 take my data and stick it inside of

0:14:05.000000 --> 0:14:12.880000
 a PPP frame. Well, during LCP, LCP is
 the first stage where a device says,

0:14:12.880000 --> 0:14:17.520000
 hey, let me negotiate some basic parameters
 with you, such as authentication.

0:14:17.520000 --> 0:14:19.440000
 I want to do authentication.

0:14:19.440000 --> 0:14:24.140000
 Well, if authentication fails, that PPP
 session will go down, which means

0:14:24.140000 --> 0:14:27.400000
 LCP will have failed as well.

0:14:27.400000 --> 0:14:32.120000
 So here where it says LCP is closed,
 that's my first indicator that, okay,

0:14:32.120000 --> 0:14:34.160000
 this is a data link layer issue.

0:14:34.160000 --> 0:14:39.180000
 Something about PPP is
 not working right.

0:14:39.180000 --> 0:14:41.580000
 Okay, so what exactly is it?

0:14:41.580000 --> 0:14:48.100000
 Well, the next thing is we can run a
 PPP over Ethernet debug to identify

0:14:48.100000 --> 0:14:53.300000
 the root cause. Debug
 PPP OE error.

0:14:53.300000 --> 0:14:55.620000
 And from here, if you're just scrolling
 through this, you know, a lot

0:14:55.620000 --> 0:14:58.780000
 of this stuff probably doesn't make any
 sense, but the stuff I've highlighted

0:14:58.780000 --> 0:15:01.180000
 hopefully draws your attention.

0:15:01.180000 --> 0:15:06.520000
 You can see here, it says, plain
 as day, authentication failed.

0:15:06.520000 --> 0:15:09.900000
 So you can see, ah, okay, it's
 a PPP authentication issue.

0:15:09.900000 --> 0:15:16.080000
 Now, if you're really adventurous, you
 can now look at the running config.

0:15:16.080000 --> 0:15:21.820000
 And here we see the running config of
 the PPP over Ethernet server, which

0:15:21.820000 --> 0:15:24.820000
 is most likely maintained by your
 internet service provider.

0:15:24.820000 --> 0:15:26.520000
 And this is probably what
 you're going to see.

0:15:26.520000 --> 0:15:27.700000
 You are the client.

0:15:27.700000 --> 0:15:31.440000
 Your router, your switch that you're
 on is a client of the server.

0:15:31.440000 --> 0:15:36.160000
 And now that you know it's an authentication
 issue, look at this.

0:15:36.160000 --> 0:15:37.660000
 We can see the issue right here.

0:15:37.660000 --> 0:15:39.800000
 Here it says the password
 is Cisco.

0:15:39.800000 --> 0:15:42.880000
 Here it says the password is Cisco,
 but know something different?

0:15:42.880000 --> 0:15:44.520000
 Look at the letter C.

0:15:44.520000 --> 0:15:46.380000
 Here we got a lower case C.

0:15:46.380000 --> 0:15:48.900000
 And here we have an upper case C.

0:15:48.900000 --> 0:15:51.820000
 PPP passwords are case sensitive.

0:15:51.820000 --> 0:15:57.560000
 So this is an issue of a
 mismatched PPP password.

0:15:57.560000 --> 0:16:00.020000
 What else could be wrong?

0:16:00.020000 --> 0:16:05.220000
 Well, if you're dealing with serial interfaces,
 serial interfaces on router

0:16:05.220000 --> 0:16:08.940000
 support a lot of different
 layer two encapsulations.

0:16:08.940000 --> 0:16:12.800000
 And whatever encapsulations selected
 on one end of the cable has to match

0:16:12.800000 --> 0:16:14.820000
 the other end of the cable.

0:16:14.820000 --> 0:16:21.720000
 For example, let me go into
 a router right here.

0:16:21.720000 --> 0:16:24.080000
 Let's go into a different one.

0:16:24.080000 --> 0:16:32.200000
 Show interface. Show IP interface brief
 because I want to see what, you

0:16:32.200000 --> 0:16:33.980000
 know, does this router have
 any serial interfaces?

0:16:33.980000 --> 0:16:39.180000
 Yes, it does. So if I go into interface
 serial 0, 0, 0, I can type the

0:16:39.180000 --> 0:16:40.940000
 command encapsulation.

0:16:40.940000 --> 0:16:44.540000
 And if I use the question mark, you
 can see here, these are all sorts

0:16:44.540000 --> 0:16:49.980000
 of layer two encapsulations that can
 be configured on this physical serial

0:16:49.980000 --> 0:16:54.660000
 interface. And whichever one I select,
 whatever that interface is connected

0:16:54.660000 --> 0:16:59.680000
 to on the other end of the cable, it
 has to be running the same thing.

0:16:59.680000 --> 0:17:00.780000
 You say, well, I'm not sure.

0:17:00.780000 --> 0:17:02.300000
 What is it running right now?

0:17:02.300000 --> 0:17:08.620000
 Well, I could type show interface
 serial 0, 0, 0, 0.

0:17:08.620000 --> 0:17:12.660000
 And what you're looking
 for is right here.

0:17:12.660000 --> 0:17:19.300000
 Encapsulation. It says in this particular
 case, it's using HDLC encapsulation.

0:17:19.300000 --> 0:17:22.680000
 So you want to make sure that is the same
 on both sides of the link, otherwise

0:17:22.680000 --> 0:17:27.040000
 you'll have a layer two mismatch, and
 the two sides of that cable will

0:17:27.040000 --> 0:17:29.940000
 not be able to talk to each other.


0:17:29.940000 --> 0:17:32.820000
 And there's one more thing
 I want to talk about.

0:17:32.820000 --> 0:17:40.220000
 And that is this idea of
 a router on a stick.

0:17:40.220000 --> 0:17:44.960000
 So a lot of times when people have
 switches connected to routers, they

0:17:44.960000 --> 0:17:49.220000
 might be doing what's called VLAN trunking
 between that switch and that

0:17:49.220000 --> 0:17:51.060000
 router. What does that mean?

0:17:51.060000 --> 0:17:54.800000
 That means that one cable between the
 switch and the router is carrying

0:17:54.800000 --> 0:17:59.440000
 Ethernet frames from multiple different
 groups that that switch knows

0:17:59.440000 --> 0:18:02.640000
 about, multiple different VLANs that
 switch knows about are all going

0:18:02.640000 --> 0:18:06.100000
 across that one cable
 up to that router.

0:18:06.100000 --> 0:18:10.020000
 Now in order for that to work, the
 configuration on the switch side is

0:18:10.020000 --> 0:18:12.840000
 pretty minimal. It's just
 like one or two commands.

0:18:12.840000 --> 0:18:15.680000
 On the router side though, at the other
 end of that cable, if you want

0:18:15.680000 --> 0:18:19.600000
 him to do trunking, we have to configure
 what's called subinterfaces on

0:18:19.600000 --> 0:18:24.440000
 that router. And each VLAN that switch
 knows about that's carried across

0:18:24.440000 --> 0:18:29.900000
 that cable has to have a corresponding
 subinterface on the router side.

0:18:29.900000 --> 0:18:34.680000
 A missing subinterface would absolutely
 cause a layer two issue.

0:18:34.680000 --> 0:18:39.780000
 Now, you might just be wondering what
 is a VLAN, what is a trunk, I have

0:18:39.780000 --> 0:18:41.740000
 no idea what those terms are.

0:18:41.740000 --> 0:18:45.200000
 That's okay if you proceed on to the
 CCNA level, you'll learn all about

0:18:45.200000 --> 0:18:48.560000
 that. But let me just show you the commands
 you'll issue and what you're

0:18:48.560000 --> 0:18:51.840000
 looking for to identify if
 this is a potential issue.

0:18:51.840000 --> 0:18:55.800000
 So number one, you want
 to start on the switch.

0:18:55.800000 --> 0:19:01.000000
 Go on to the switch and issue the
 command show interface trunk.

0:19:01.000000 --> 0:19:04.220000
 Now if you get nothing,
 no output, you're done.

0:19:04.220000 --> 0:19:06.900000
 It's not a router
 on a stick issue.

0:19:06.900000 --> 0:19:10.600000
 But if we do get some output like right
 here, we can see the interface

0:19:10.600000 --> 0:19:13.700000
 fast-heath and at zero
 three is trunking.

0:19:13.700000 --> 0:19:16.620000
 Otherwise it would not have
 showed up in this output.

0:19:16.620000 --> 0:19:19.400000
 Now you might say, oh, I think this
 is the interface that's having the

0:19:19.400000 --> 0:19:22.500000
 problem. Okay, let's find out.

0:19:22.500000 --> 0:19:27.120000
 So the area here that I've highlighted tells
 you the VLANs that this particular

0:19:27.120000 --> 0:19:34.160000
 switch knows about.

0:19:34.160000 --> 0:19:36.480000
 So the VLANs are carried
 across this trunk.

0:19:36.480000 --> 0:19:40.980000
 Now once again, if you don't know what
 this term VLAN means, that's okay.

0:19:40.980000 --> 0:19:44.220000
 The main thing I want you to take out
 of this is this command right here

0:19:44.220000 --> 0:19:47.640000
 is showing you the VLANs
 allowed on the trunk.

0:19:47.640000 --> 0:19:50.960000
 And we're going to match that
 up with the router side.

0:19:50.960000 --> 0:19:57.060000
 So now on the router, we
 do the command show run.

0:19:57.060000 --> 0:20:00.540000
 I couldn't put all of it in here, all
 the output, but show run and you

0:20:00.540000 --> 0:20:03.860000
 want to scroll down to the interface
 on the router that's connected to

0:20:03.860000 --> 0:20:07.400000
 the other room. So you look at the switch,
 you say, okay, fast-heath and

0:20:07.400000 --> 0:20:09.300000
 at zero three, here's
 the cable right here.

0:20:09.300000 --> 0:20:13.920000
 If I trace the cable, oh, it's plugged
 into fast-heath and zero dash one

0:20:13.920000 --> 0:20:16.980000
 on the router. Okay, show run.

0:20:16.980000 --> 0:20:19.660000
 Take a look at fast-heath
 and at zero slash one.

0:20:19.660000 --> 0:20:23.820000
 We know that on the switch side, fast
-heath and zero three is trunking.

0:20:23.820000 --> 0:20:28.420000
 So right there, if it's trunking, we
 know that on the router side, his

0:20:28.420000 --> 0:20:33.140000
 physical interface needs to be
 subdivided into sub-interfaces.

0:20:33.140000 --> 0:20:35.180000
 How do I know if I
 see sub-interfaces?

0:20:35.180000 --> 0:20:39.920000
 Well, I see that same number, zero slash
 one, repeated with dots and other

0:20:39.920000 --> 0:20:44.080000
 numbers. zero slash one dot
 one dot two and dot four.

0:20:44.080000 --> 0:20:49.380000
 So these right here are considered
 sub-interfaces of our main physical

0:20:49.380000 --> 0:20:51.840000
 interface, fast-heath
 and at zero slash one.

0:20:51.840000 --> 0:20:55.360000
 So check, we do see the sub
-interfaces, that's good.

0:20:55.360000 --> 0:20:59.960000
 Now, going back to here, we
 see VLANs one through four.

0:20:59.960000 --> 0:21:03.260000
 Do I have a sub-interface
 for each one of those?

0:21:03.260000 --> 0:21:05.320000
 And here's where we
 see the problem.

0:21:05.320000 --> 0:21:09.020000
 Look at what's highlighted here
 in yellow, dot one Q one.

0:21:09.020000 --> 0:21:14.360000
 That is a sub-interface specifically
 used for VLAN one, dot one Q two.

0:21:14.360000 --> 0:21:16.360000
 That's a sub-interface for two.

0:21:16.360000 --> 0:21:18.300000
 Here's a sub-interface for four.

0:21:18.300000 --> 0:21:22.300000
 What's missing? There's no sub
-interface for VLAN three.

0:21:22.300000 --> 0:21:26.860000
 So VLAN three traffic that's going
 up this trunk from the switch once

0:21:26.860000 --> 0:21:29.080000
 it hits the router
 is being dropped.

0:21:29.080000 --> 0:21:35.120000
 Because there's no corresponding layer
 two interface to support that VLAN.

0:21:35.120000 --> 0:21:39.140000
 So that would also be a
 data link layer issue.

0:21:39.140000 --> 0:21:41.220000
 And that pretty much wraps it up.

0:21:41.220000 --> 0:21:45.720000
 So that concludes this video on identifying
 and troubleshooting physical

0:21:45.720000 --> 0:21:51.180000
 layer and data link layer issues
 on hosts and routers.

0:21:51.180000 --> 0:21:52.360000
 And I hope you found it enjoyable.