 My name is Ken Mayer and I'm going to be your instructor for this course. Now I've been involved in the world of IT since the very early 80s, working with a variety of different technologies. Of course that also includes Cisco. I've been around the world of Cisco networks, working on routing and switching as well as security, voiceover IP and wireless. Ever since practically these tools came out, these different technologies as Cisco evolved. I've also done a lot of work with other competing interests, being able to work with the same types of routing protocols, the same infrastructure protocols for probably almost all of the large service provider networks around the world. So my hope is, is I'll be able to take that knowledge and experience and be able to help relay all of the things that we're going to talk about while going through the Cisco networking devices and to be able to help make every part of what we're going to talk about as clear as I can. We're going to start off by talking about troubleshooting your VLAN connectivity. Now as an overview, a VLAN was designed to be able to separate Layer 2 environments into separate broadcast domains. Remember the problem we had at Layer 2 was we have a bunch of switches that are interconnecting all of the host machines. That is, if any one host sent out a broadcast like an ARP request, it would be transmitted what we call flooding to all of the different devices, whether they wanted to hear that or not. And so one of the parts of the use of a VLAN was to create that broadcast domain so we could limit the traffic to a group of hosts that had common connectivity issues. So it is a way basically of being able to create independent segments or LAN networks, as I said, to isolate that broadcast domain. And we get a lot of other really cool features that come through the use of VLANs. Because it is a broadcast domain and by best practice each VLAN has its own separate IP subnet, we now need a Layer 3 device to be able to get from one VLAN to a different VLAN. What that gives me is that segmentation that I just talked about with the broadcast domains. But it also gives me the ability now to start controlling traffic as it goes from one VLAN to the other through my Layer 3 devices through the use of security. Whether it's a firewall or a router running an access control list, we have the better capability of controlling that flow of traffic. And it also gives us flexibility in the design of our networks because we can actually have different hosts maybe on different floors of a building be able to stay in the same local network as perhaps a printer on a different floor or a file server on a main floor or at a server farm. The goal is that we have that capability of designing our network with what looks like Layer 3 because it does kind of have to go through Layer 3, but still being done at the switch side, which means that we're getting the faster performance of using our switches for forwarding traffic than we would have if we had to go through a router. Now when we create a VLAN, the actual syntax, the commands we type in are very simple. And remember that the VLANs are going to be any number from 1 to 4094 that you can choose to use. I don't think the number of the VLAN is quite as important as the part where you configure the name. Let me try to explain that. So first you go into this configuration mode and then in configuration mode you just type in the command VLAN with the VLAN number that you want to create. Now remember, this does not assign an interface. And that's important because we still have to figure out how to assign an interface to the VLANs. And we'll see that here coming up in just a couple of seconds. But I think what is really important, I'll put the exclamation point by it, is the name that you give the VLAN. Every VLAN will have a name by default, but it won't be a name that's reachable or readable I should say. It's got to be a name I think with a good naming convention so that when you're troubleshooting, and think about this, we don't configure our switches every single day. At least I would hope not. Once the network's up and running, unless we introduce some sort of a change or an upgrade or have maybe a different traffic flow, we're going to leave these things running for months on end. And so, you know, eight months later, if you're trying to remember what a certain VLAN went to, well, hopefully you have it very well documented, but just having a really cool name like switchlab99 or human resources floor A, building A, something that helps you remember what that VLAN's for makes it easy when you come back in that eight months later to start making changes or to start doing some troubleshooting. All right, so once we get to that point, and then all you have to do is put the name in, and then by the way, type exit, and then you'll be back in configuration mode, not in the config VLAN mode. From there, the next thing you do is you're going to go to the port that you want to assign the VLAN to. Now, important, this is basically an access port. We are going to see and talk about trunk ports later, but an access port is that port that is going to place the VLAN tag on incoming frames and take the tag off before it leaves. So if you can imagine my switch being here with all of my ports, it's a pretty low model switch here, it's got four ports, and I have a computer connected to this one. The computer doesn't know, the host doesn't understand what a VLAN tag is, might actually read it as a frame that's gone bad, and so as it's sending its frames in here inside of the switch, that access port, as I said, would attach the VLAN number, whatever it was that you assigned to that frame for the purpose of then being able to look and see which ports it's allowed to transmit out of. Remember, if you think about the review, that I've reassigned two or more ports to a single VLAN that that traffic could leave any of those ports, access ports, that are assigned to the same VLAN. It does depend on the destination MAC address that we're looking for. There is a special port called a trunk port, and that's coming up in a couple of our pages here, that we'll carry, if you want, all of the VLAN traffic so we can get to a different switch, but not the access port. So having said all of that, what we've done here is we've assigned to interface 02, we use the command switch port, switch port, meaning it's a layer 2 port, not a routed port, layer 3. We said it's going to be an access port, and we're assigning it to VLAN number 2. Now there is the ability to add an extra VLAN if you wanted to to a switch port, but we use it for the voice over IP, for the phone traffic to keep it separate from our data traffic. So you might see, you know, when you hit the question mark after one of these commands, you might see that ability to add a second VLAN, but just remember it's specified for a specific type of traffic, that being your phones hooked up to the switches. So basically that command now is assigned, FastUthernet interface 02 to VLAN number 2. And as I said, as an access port, it's going to add or remove the VLAN depending on the direction that the traffic is flowing into or out of the switch. One of the things you're going to see by the actual configuration with a command such as showVLAN, what you're going to see is that every port by default is in the VLAN called 1. That's a default VLAN. We actually are going to refer to it as a native VLAN. The reason that's important is that we technically never put the VLAN tag of the native VLAN in any of our frames. It's considered untagged traffic. So that means we really, even though all the ports by default are in VLAN 1, doesn't mean that they are access ports. It also doesn't mean that they're doing anything with tagging the traffic. That will occur with the non-native ports, like the one that we made just a little bit ago, VLAN number 2. So what we're seeing here is that we have one port that's in there. And you'll also notice that it talks about the status of this VLAN being active. So what does it mean to be active? Again, I'll draw a little picture of my switch. If I were to make a VLAN, let's say I made VLAN 100, I would assign any interfaces to that VLAN. Then that VLAN is considered to really be non-functioning because in order for a VLAN to actually be active, you have to have at least one port assigned to that VLAN, and that port has to be up and up. So if I decided to attach all of these ports to VLAN 2, as long as one of those interfaces is up and up, then that VLAN will be considered to be active. That's going to be important when we get later on to start talking about things like the VLAN interface and how we do the inter-VLAN routing. If you remember, the definition I gave you with the VLAN is that for every port that is an access port in that VLAN, that the traffic coming in can only go out of port that's in the same VLAN. So I'm putting the letters here, red, green, and blue, as they've indicated them here. And you may notice that I have a device in the blue VLAN, and on the other side, connecting to a different switch, I also have a device in the blue VLAN. So how would I accomplish being able to get the traffic coming from, let's say, host A over here to host B on the right-hand side? Well, I would have to have at least one interface that's in that blue VLAN so that we could stake by the rules, and that says that we can send our traffic across a port that's in the same VLAN. But also with the red and the green VLANs, I would need to have multiple connections, one for each VLAN, and that would be a waste of the ports that you would have on your switch. The reason to that is what we call a trunk. And the trunk operation, by default, was designed to carry all of the VLAN traffic from one switch to the other. Now that, in a way, means that the trunk, you could think of it as being a member of all VLANs, and that is the default, like I said, all VLANs will go across. The thing about a trunk, though, is unlike the access port, the trunk does not remove the VLAN tag. The VLAN tag remains with the frame as it goes from one switch to the next. So when it's received by this second switch over here, it's still going to make sure that it can only leave ports that are attached to that same blue VLAN. That's, again, if A was transmitting to B. And so that's going to continue to happen with all of the VLAN traffic. Even if you have multiple switches out here, you would always create trunks between those switches so that you would be able to carry all of the VLAN traffic from one switch to the other. That, again, is how we then can basically divide our network, as I said, into segments. That makes sense, as well as being able to help create those broadcast domains. And as I said later, when we talk about how to get from one VLAN to the other at layer three, that's when you could also implement some security. When you're configuring a trunk interface, one of the things you need to know about Cisco switches is that they have what's called the dynamic trunking protocol. That means that the ports on a switch will automatically become a trunk if one of the two sides initiates a request. Now, by default, they're waiting for a request. They're not actively trying to do dynamic trunking protocol. So you would have to at least make sure one of the two sides of the switch initiates the trunk connection. You could also just manually create it as a trunk if you wanted to. So what we're going to see here in this example is for port 11 anyway, is that we want it to be a VLAN trunk. We're also going to change the native VLAN. Remember, the native VLAN is actually a VLAN that will never see its tag put onto any frame. We often use that for management purposes and also to negotiate the trunks between two switches, untagged traffic. So what we do is in the configuration mode, go to the interface we want to configure, so interface FA011. From there, we use the command switch port mode trunk. That is statically making that a trunk port. We're also looking at a command that allows you to be able to take that trunk and change the native VLAN. Now, if you change the native VLAN like we did to VLAN99, and it's a very common occurrence, we do that for security reasons so that we hope that nobody really knows which is the untagged traffic that we use for management. But when we do that, it's important that the trunks on both sides, not every trunk that you have from one switch to the other, but the trunks between two switches have to agree on the same native VLAN, or that trunk will not show up. Now, technically speaking, if I start changing the native VLANs, then I would assume all of the trunks that I'm using on a switch would have the same native VLAN. So again, just make sure those match up and make sure that both sides either have that dynamic trunking protocol or that you've configured both sides to manually become a trunk, so that we can carry all of that tagged traffic from one switch to the other. The show interface command by itself would not tell you about the trunking that you have set up on an interface. So when you could add that command, show interfaces FastEthernet011, we add on the option of switch port. So it shows me the Layer 2 settings. Now, in this case, since we created one as a trunk, you'll see that administrative mode as a trunk because we said manually it's going to be a trunk. It's operating as a trunk, that's good. At this point, we don't see any type of errors of this interface saying that it's not coming up or it's not working. Now, in this case, remember I said the dynamic trunking protocol, DTP, is a feature that you could use. In this case, the negotiation of trunking says it's on, so that means if I created a trunk on one side, we would hope that it's now trying to create the trunk on the other side. And we also see the verification that we changed the native VLAN. The native VLAN, again, is that untanked traffic. If we look at another command with the show interface, but adding the word trunk, it gives us more or less a summary of the trunking situation and lets you know that the trunk mode is on. The encapsulation, by the way, the 802.1q is a part of that IEEE specification that we use for tagging traffic. There was a time back in the early days where Cisco was coming up with these cool ideas, especially with this traffic. They had a protocol called ISL, inter-switched link. Don't worry about it. We don't use that as a default anymore, but it gave us some really cool features that nobody else had until the 802.1q protocol had been revised. And we're going to actually see some of those features as we start talking about the instances of things like spanning tree. Anyway, so back to this, we see the encapsulation tells us how the tags that we're using and the statuses that it's trunking and the native VLAN, again, 99. So here's DTP, the Dynamic Trunking Protocol. Now, again, the idea behind this is that it is on by default with all of the different types of ports, but it's in dynamic auto, which means that neither side wants to initiate this. So if I have both sides of my trunk link running dynamic auto, then it's actually going to be an access port, not a trunk. This has to be turned on as desirable, because you can see that no matter how we set that up, if either side is desirable, the others on auto that we're going to come up with a trunk or if they're both indesirable, they'll negotiate themselves as a trunk. With DTP turned on, and what we saw here when we manually created a trunk port, as this one did, that it does automatically become a trunk, even if both sides are manually done. And then, of course, from there, if either side says, no, I'm an access port, well, guess what, we're not going to get any type of a trunk. And if you have one side that's manually configured as a trunk and the other is as an access port, then you'll notice that you have limited connectivity because those two interfaces are basically at odds with each other as far as whether or not they're trunking. Now, one of the big things you'll see here, and this is a security issue, is that you notice we suggest that you do manual configuration for a trunk. The reason behind that, as I said, is a security issue, is that if every port is designed to do DTP, and let's say I have a hacker that's infiltrated my network and they've connected this port, they could run DTP on their laptop. It's not at all hard to find that protocol to download and install it and running. And then, suddenly, they would become a trunk with your switch instead of an access port. The downside of that is remember a trunk carries all my traffic, so if I had traffic come into one trunk port, it would then be available potentially to the hacker to be able to see and to capture because, you know, again, the switch is actually thinking it's talking to another switch. So it's going to continue to move that most of that traffic, a lot of it, broadcast especially, over that trunk port. We don't want that. So we need to make sure we manually do that and make both sides a trunk. And to go a little further, you also want to make sure that every, and we'll talk about this a little more in security, that every other port that will never be a trunk should be manually made an access port for the purpose of avoiding that potential problem of somebody trying to negotiate a trunk. Now, the commands that we showed you for troubleshooting VLANs start off with things like the Show VLAN. Remember the Show VLAN is going to give you a list of all the VLANs and I said VLAN 1 is there by default and we created a VLAN 2. And the other part of that is it's going to show you the port or ports that are assigned to each of those VLANs and give you the message as to whether or not the ports are active or the VLANs are active or not. And again, remember the VLAN to be active has to have at least one port assigned to the VLAN that has its status as up and up. So if I'm having a problem that say with two computers not talking to each other and they're in the same VLAN, I'm getting good at drawing my little three dimensional switches I think here. And so let's put a couple of ports and at this point, I'll create two VLANs. I won't worry about the trunks. I'll kind of divide it over here. We'll make this a VLAN 10 and a VLAN 20. And the first step says there's no connection between the PCs that are in the same VLAN. So I'm imagining I've got a PC over here and a PC over here. They're both connected to ports in VLAN 10. So the first thing we do with the Short VLAN command is make sure the port's in the correct VLAN. Let's ask that question. Did we make a misconfiguration of what we thought was supposed to happen? Did we notice that one of those two ports is not in the VLAN we expect? Then the solution is simply to assign it to the correct one. Now, the reason that's important, again, remember, we do forwarding based on destination MAC addresses. And when traffic enters a VLAN and we look at the MAC address table for forwarding, we're only going to look at the MAC addresses that are in VLAN 10. So that means if somebody's in a different VLAN that we'll never see that in the MAC address table, now, if the port is in the correct VLAN, the next one that says is the VLAN present in the VLAN database. All right, well, that's, again, going back to the show VLAN command to be able to see if it actually does exist. If you do a show interface, especially when you add the switch port, you'd be able to see if it's an access port or a trunk port because that's also important. We want these to be access ports connecting to these machines. So if the VLAN's completely missing then, obviously, there's a problem. You would want to create that VLAN and then after that's done and you test it again, we hope that now we have a successful connection between the PCs and the same VLAN. One of the things it doesn't say here, but just remember this, is, again, they both should be, by best practice, in the same IP subnet because even though we're going through the switch, computers are still looking at a destination IP address and if they're in different subnets then also we wouldn't have any communications. So I'm kind of adding that on as an extra piece of troubleshooting, although that technically is not a VLAN issue that now becomes a routing or an IP issue. As I said, when we look at the MAC address table, the destination MAC addresses that are listed there are going to be separated by VLAN. So when traffic comes in a port, as I said, with a specific VLAN assignment, VLAN 10 or whatever that may be, then when we look at the destination MAC address, we're going to look at that MAC address table, but only restricted to the VLAN that's assigned to that frame. In a way, we're kind of filtering what we can see out of the MAC address table and that's important because that's how we're separating the ability for traffic to be able to not basically hop a VLAN. We don't want that. We want to have that segmentation or isolation to the use of VLANs. Now, when we use that same switch port option on a show interface command, as we just did for the trunk, here we can see that we statically made this an access port administratively. That's how it appears to be working. It's still going to do the .1 queue, part of the encapsulation, and in this case you might have noticed, here is a little troubleshooting, that the access mode for that VLAN 10 says that it's inactive. So inactive could be that you're missing a VLAN, as I said before. So assuming that this port is up and up and was assigned to VLAN 10, the question then becomes, did we actually create the VLAN 10? Now remember the goal of the trunk links between two switches is to carry all of the VLAN traffic. So in this case, if I have two switches and I have them connected with the trunk, I kind of like to make it look like a little pipe or a tunnel because it's carrying all those different VLAN numbers across here between them, but it is a trunk. And so let's talk about some of the troubleshooting. Of course, we can do the show interfaces trunk just to see if it is in a trunking mode. Don't forget we also had the switch port option under the show interfaces to also look to see how it was set up. So basically what we're saying here is if we are having problems with communications between the switches, the first thing we want to look at is the local and pure native VLANs to make sure that they match. Remember we made an example where we said the native VLAN is 99, the same native VLAN is untagged traffic. And here's what would happen if we didn't do that. Let's say I made an access port and I said let's make it VLAN 99. Well the traffic comes in, now it's going to have a tag of 99 on it because we didn't make it native and that's going to come across this trunk link over to this switch that's going to see a 99 and say hey, wait a minute, that's not supposed to be on any of my frames coming through here. It's an untagged management type of VLAN so it then gets that confusion. And vice versa, if something came in here, maybe from another switch with a tag of 99 this trunk is going to basically ignore that 99, take it off of there, send it across and then again confusion. So change the native VLANs to make sure that they match. The other thing we want to look at are the local and pure trunks to make sure their modes match. Again, if you created this as an access port on this size and you manually made this trunk on this other side, remember what the result was? That's right, traffic that was inconsistent or basically non-existent. So I don't care if one side's doing DTP and the other you manually assign a trunk, I mean you can do a lot of those options as long as the both sides are agreeing to be trunks and at a best practice statically configuring both to be trunks. And if that's done same native VLAN then you should have an operational trunk that's now carrying out. Alright, so here again we're using the show interface with the trunk option to kind of see the summary. In this case you notice that this one's mode is auto, this one's mode is auto because we're looking at switch one and switch two and what happens if they're both in auto? If they're both in auto, remember we said that neither one of them would initiate being a trunk and we're seeing it, right? The status says hey, I'm not trunking at all. I might have it on auto but nobody has said either way on either side that we can become a trunk. So that can be a problem. The other issue that you might want to look at is the native VLAN mismatching, right? We also want to make sure that that's set up so we can kind of cover two areas of troubleshooting with one command by doing the show interface name and number and then followed by the command trunk so we can then look back at our documentation and decide which is the correct native VLAN and what we're going to do with the modes if we're going to statically make it a trunk or try to make one at least auto desirable. Well, I hope as you went through this that you got a little bit more information, more in-depth information about the VLANs and again it is a way of creating separate broadcast domains that can span over multiple physical segments meaning multiple different switches. One thing a VLAN does not do is survive going through a router. You just need to know that because the router is doing everything at layer 3 and we'll talk about that inter-VLAN routing a little bit later. Trunks are how we carry multiple VLANs across from one switch to the other without having to burn up physical ports one for each VLAN I configure. We have the dynamic trunking protocol that can automatically negotiate a trunk. It's not recommended we tell you to use a turn it off basically and make it manually a trunk. Also verify that the ports that you use are in the correct VLANs whether access ports so that you can have host to host traffic or whether or not you have the same VLAN configuration set up on the trunk links as well such as the native VLAN that I was talking about before because that will also bring down a trunk.