Checking the fundamentals

- [Instructor] Before we get to troubleshooting Cisco switches in particular, I'm about to say really the most important thing in the course to you right up front first video right here right now: Don't make troubleshooting harder than it has to be. Remembering that it's going to give you more points in the exam room, it's going to make network troubleshooting a lot easier and faster and here's exactly what I mean by that. Sometimes the solution to a networking issue is complicated obviously but usually, it's pretty darn simple, usually it's right in front of you.

Don't start with the most complex solutions, start with the simplest ones. You keep it simple and you use the OSI model as a troubleshooting tool. And hey, I told you you'd use it one day. If you got your CCNA with me when we go through, you'll learn all the models and you see what happens to each layer and it's not the most exciting material in the world. And I think I can speak for you when I say that when I learned it years ago, you know you're going through it's just like, boy this is boring (laughs).

I'll just go ahead and say it. The OSI model and the other models TCP model and then everything that's going on, it's not the most exciting thing, you're not really on the life equipment, you're not really doing anything yet but as I tell people you know, I always want to tell people things I wish someone had told me when I was earning my CCNA and CCMP and especially with the NA. And I said, look this is really going to come in handy, know your OSI model and use it as a troubleshooting tool because I'll tell you right now in my decades in the business and your time in the business you've seen the same kind of network troubleshooters.

You've seen those that have a structured mythology well I'm going to check this and then this and then this and those who don't or really don't know where to start so they're just kind of throwing stuff at the wall to see what sticks logically of course. My first thought each job was actually in help desk. And I was astonished really to find out how many issues were resolved by getting the customer to realize that what they were working with wasn't actually getting any power 'cause if the physical layer isn't working ain't nothing working.

It's just that simple and that's why I like to use the OSI model as a troubleshooting tool because once you know where everything is good at layer one, you up to layer two and later in the course, we're going to see when we're working with some layer three protocols that you have to be wary of certain things happening at layer two. None of this happens in a vacuum. Routing doesn't happen in a vacuum, there are other things going on and on top of it in the OSI model and especially beneath it at the data link layer. Speaking of layer two, let's take a look at a very simple switch scenario.

We've got routers two and three connected to switch one and they're obviously on the same subnet and they have consecutive IP addresses and they can't ping and... And I thought we might be off line there, sorry about that. So let's head over to router two. And of course ping is always a good place to start with troubleshooting but it's a little bit limited. It just says, hey we're not getting there and you're going to take my word for, and actually we don't have to take my word first, give it a three.

Now I know you're thinking why are you pinging two from three when you couldn't being three from two. And in a smaller lab like we're working with here, I grant you it probably wouldn't work but in rare occasions and more advanced labs especially if you've got your eye on the IE, you'll see scenarios very rare but they do happen where A can't ping B but B can ping A. That obviously is not the issue here though, so we know they can't talk to each other. What are some basic commands here that'll help us get the lay of the land because what we have here is a diagram with a couple of IP addresses and you know it never hurts to check those because I'm going to paraphrase a guy I talked to many years ago.

The network diagram ain't always right. And it's not, you kind of looked at ones that had incorrect numbers on them, so it doesn't hurt to check that and we doesn't hurt to check the state of the interfaces either because if the interface is shut down, what state is it in, it's an administratively down state. First thing you learn an IP routing, right? So let's go ahead and take a look at the interfaces in question. And we're really just concentrating on the top lines here and there's your MAC address, your IP address, it has an IP address so you're good there.

But what we're really interested in is this line right here, FastEthernet0/0 is up, protocol is up. As a refresher, as to what exactly that means, the first part of it refers to the physical state of the interface, the second part to the logical state. So usually with an Ethernet interface, Ethernet based interface I should say, you're going to see either up and up or down and down, you can't see the physical interface up while the logical state is down but that happens more on serial interfaces when you're working with different end cap types like frame relay and PPP.

So everything looks pretty good over here on a router three, let's take a look at router two. And again this is just a refresher, just to remind you to look at the simpler things first, make sure this baby's got an IP address, make sure it's up and up, that kind of thing before we start getting into some more complex solutions. And everything actually looks pretty darn good there. So how can I make absolutely sure and this is something you really want to check (laughs). With some network maps out there in the real world, they're pretty bad about those.

Let's say you were told, oh well router two is connected to port fast 02 on the switch and router three is connected to fast O3 on the switch. Let's say I told you that verbally, well I just did, but let's say that it was actually on the diagram but you wanted to verify it because as veterans and my videos are about say we don't mind trusting but we always verify. How can I make absolutely sure that the physical connections are what I think they are or what I'm being told they are? And that's where CDP comes in.

Show CDP neighbor, CDP of course cisco discovery protocol, cisco proprietary protocol. You can't run it on non cisco devices but it's really helpful in making sure that your cables are where you think they're supposed to be. And going from left to right here in the non detailed version of this command, you can see it's going to give you the device ID, the local interface and frankly well I'm much more interested in the local interface and the port ID 'cause the port ID at the far right is telling you it's connected to fast 0/2 on the switch.

So if you were just making yourself a little network diagram either in the exam room or in the real world, this is how you do it. CDP is a great help as long as you have all cisco devices of course. Now this is telling me that Fastethernet 0/0 is connected to the second port fast 0/2 on the switch, so that looks good to me. And then I'm going to run the exact same thing over on three and just make sure my cables are where they're supposed to be and that they are connected of course. And you can see device ID switch one, local interface Fast 0/0, port ID fast 0/3, so so far so good.

Now, we ought to go check things on the switch and just make sure everything's what we think it should be there and we'll run show CDP neighbor. And of course what I want you to get used to here is seeing other devices because of course in an exam room or certainly in a production network, it's not like you're just going to see the one port you need information on right, you're going to see all of the CDP. So it would appear as though switch one is connected to a switch two, I'll slide that over just a bit there, and you can see it's connected to switch two via ports 11 and 12.

And you can also see it's connected to routers two and three, it matches what we saw on the routers that the local interface is two and three are connected to our FastEthernet 0/2 & 0/3. And on the remote devices they are connected to their Fastethernet 0/0 interfaces, their respective interfaces. We also have a router four that we just might talk about in this lab but right now we've gathered the information so far that we know exactly what ports are connected to routers two and three and they're up and up, we could run a show interface fast 0/2.

And we don't expect to see an IP address 'cause we're running this as a layer two switch but we see up and up and even connected in paren there in the first line of the output. So, so far so good, won't hurt to check three and we're up and up there so everything's good. So what else could be causing an issue here, what else would I check on a layer two switch. I've checked all the physical connectivity, I'm good at layer one. What other layer two feature might we have on a switch here that could be causing this kind of connectivity as your issue? The next thing I would check are my VLAN memberships.

And this is the full show VLAN and I know the lines hitting it right there, let's move that up, and you can see that we have a whole mess of interfaces in there and VLAN one which is of course our default. And going down it, looks like we've got some VLANs that some non default VLANs that have already been created. And we've got VLANs two three 10 20 30 and 40 and we have a problem because port two is in VLAN two, port three is in VLAN three.

And the only way we can have inter VLAN traffic is what? What do we have to get involved? We have to get layer three involved because layer two switches are not going to be able to handle inter VLAN traffic. So that's your likely issue right there. And let me introduce you in case you've forgotten, I don't think you have, to show me VLAN brief. This really cuts all it, just cuts all the information off there at the bottom and it shows, let me just give you that right there, it shows just the VLANs that have actually been created plus the five defaults but it leaves that extra information about the set and the MTU off which generally you're not going to need.

So what do you think? Let's try putting them in the same VLAN and while we're at it, let's go ahead and put VLAN four in there as well because we're going to add VLAN four to the mix. So what do I do? I could use the range command here. VLAN 234 and you get a little message, Access me line does not exist, but it does create it for you which is awfully kind. And you know what I'm going to do there? Remember what that switch mode act command does? I haven't stopped talking now, well I guess it did stop talking (laughs).

What I meant was, I wanted to give you a moment to talk to yourself in public or private. So now we've got VLAN 234 all the ports two three and four are members of VLAN and the switch mode access command makes it an access port which means that port can belong to how many VLANs? One and only one, which means it cannot do what, trunk. So switch-mode access, a good command, I went in and put it on there was probably on there already but I wanted to make sure these are access ports and we're good to go there. So we've got the same VLAN, we've checked everything else at layer one and layer two, so we just might be good to go.

Now, is that trunk involved? Remember that? Let me just do a quick show VLAN, actually should quick show CDP neighbor. Do I have to be concerned about this trunk between routers one and two that I think exists, I mean I haven't verified it yet. I don't really have to worry about that right now though because the two ports in question that couldn't ping each other on routers two and three, they're on the same switch. So that traffic is not going across the trunk. And that's another key to troubleshooting and this is a small example but you don't want to spend on troubleshooting things that don't matter.

And right now all the traffic's on one switch, I'm not worried about the trunk. If the trunk is not working, I'll get another phone call. But let's go to router two now and do a ping 23.3. And it's okay to lose that first ping packet when you send your first successful ping over. If I send this one, it should go a 100% and it does, so we're looking good there. Let's not do that, let's do a ping 172.12.23.2.

Looks good, so we have solved that issue and I don't say more importantly but just as important, we had a good review there of CDP, couple of show interface commands, basic troubleshooting commands you learned about earlier in your CCNA to tend to leave them behind as you get involved with more complex routing protocols that kind of thing. How about that router four though? What about pinging 172.12.23.4. Is using my numbering that's usually what I do, is like on router four, I end all my IP addresses in four, it's a good lab organizational tool.

Does it look good though even though they're on the same VLAN. Well, let's get a little practice in here. We're at 13:20 and I usually don't go this long but we don't have that much longer to go here in this particular labs, so let's hang in. Most of the videos if not all of them, they won't be 15 minutes long. So let's do a show interphase faster 0/0 and router four, and what's the problem? It's up and up, we love that but this is so easy to miss and you're not going to miss it.

Check that IP address, the IP address is 234. See we didn't see it on the diagram and if I go down and I'm not trying to trick you, this is not a course in tricking you, but let's say that we took a look at this particular diagram and you thought okay, 172.12.23.4, why can't it ping and I don't know why. First thing you ought to do is verify that IP address. Anytime something on a network map or diagram is giving you a little bit of trouble especially if it's handwritten (laughs), especially if it's handwritten, you want to check that address.

So what I will do during the break here, actually let's go ahead do that, we can do it right now. Go to the top. So and then you just put the IP address back on. So it should be 23, right? And now let's send those pings over and there we go, we lost the first one.

The next one it was 80%, we're good. And we'll go ahead and resend those pings from three, once the first one it's fine, and we're up. So nothing complicated there. We had a couple of couldn't ping scenarios but again we got to review VLANs, we got to review CDP neighbor, show interface commands that kind of thing and that's not always of course the solution but it was definitely the solution here and the first thing you want to check, you want to keep your solutions simple at first. And the very next video, I will set up a separate lab for you and we'll take a look at some kind of passwords, I guess you can call them that, you'll see what I mean on the very next video.