Cisco CCNA - VLANs | Matt Carey | Skillshare
Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
4 Lessons (43m)
    • 1. VLANs

    • 2. Access VLAN Configuration

    • 3. Trunk Configuration

    • 4. Trunk Pruning


About This Class


This class is intended for CCNA students that want to learn more about how VLANs work in networking. You will learn how to configure VLANs, access ports and trunk ports. 


1. VLANs: in this section, we're going to learn how to configure, view lands on switches in the different switch support modes that will be used for villain assignments. Okay, so let's start out with the basics. Let's say we wanted to assign Host A and host. Be here to villain, too. First, we have to go to these switch configurations and actually globally define the land, too. So the first step, when configuring villains on switches, is to define the villain. If the villain is not defined on the switch, that switch will not pass traffic for that villain. Once our villains are defined, then we have to configure our switch sports for that villain. So for user A and User B's traffic to be assigned to the land to, we have to tell the switch port to do so for this type of set up. Since we just have and hosts that do not understand villains and we're simply just trying to put their traffic on villain to, we would use what's called an access motive Port access mode. Ports simply just assign any traffic coming from the connected device to the villain that you define in the configuration and any traffic ee grassing, A access mode port is considered to be on tagged, meaning that it does not have any V land tag assignments because computers any type of device that you would connect to an access mode port. We don't assume that at supports villains or understands beyond tag. So when the traffic sent back to the devices that are connected to access more ports, it has no villain information. So now we've configured the ports. That and host are connected. Teoh. But what about between the switches for this example? Since we're only using one billon, we could actually configure the switch to switch connections the same way with Access mode bill in two configurations. And then we would have villain to define throughout the switched path. So that configuration is fine for this example. But what if we had other villains connected to these switches? If any veal and three traffic were to be sent out of these inter switch connections, the traffic would be dropped because we're only passing traffic for villain to in this access mode inter switch configuration. So for this scenario, since we need to pass multiple villains across these ports, then we would use what's called a trunk mode port. So with a trunk mode port, the switches would actually USVI land tags to assign to the traffic coming from the connected devices so that switches across the land would know what villain to send the traffic out to. So let's take a look at how this configuration would flow if user A and user see or to sun Ethernet frames to switch one. So here comes user sees, frame and use a raise frame. And since they both entered their access mobile imports, the switch would assign the corresponding villain to that traffic when their frames were going to be sent out of the switch. One poor connected to switch to which one would add be land tags to those frames, since the reveal and tags assigned to these frames now switched to knows which villains to send the traffic to. And that's how we can have multiple villains traverse a switch port. Let's look at a quick comparison of access mode and trunk mode. Ports access mode Ports would have devices like computers, printers or cameras connected to them. Trunk mode ports would have devices like switches. VM hosts and autonomous or flex connect access points connected to them and just always remember that traffic leaving an access mode port is going to be a ntags and traffic leaving a trunk mode port is going to be tagged. 2. Access VLAN Configuration: Now we'll jump into our lab switches and star configuring RV lands, and we'll start with our access Leland configuration. Here on core one, we'll configure villain to globally toe. Add the deal into the switch. Verify we see an interview and database, and then we'll configure our port for user A to be an access villain, too. Figure BLN, too, and then we have the option to name it. Let's name it user A. An important thing to know about villain ads in your configuration until you exit out of this bill and prompt the villain is actually not applied. I have this villain previously configured, so we'll see it in the database. But the name change will not take effect until I exit out of the fig. The land sub mode. As you can see, I have the name switch management. Let me exit out of this be land sub configuration. And now when I run, show Bela 92. You see that it's applied my villain configuration and renamed it to user A. Let me pick which interface to use. Four. User A. I think we'll use port 13. That's interface affluence that zeros last 13 and we're going to say first switch port. Whenever you're configuring any layer to port the command switch port is going, Teoh actually make the interface a layer to interface by default. Layer two switches should have sweet support as the default If you ran no switch port, that would actually configure the interface as a layer three interface where you could apply an I P address to use it for routing. So switch support and I'm gonna say switch port mode access. Since I want this to be an edge port and I wanted to use an access villain, I want to put it in access mode So it sport mode access that's statically, defining the port as an access port to only be able to use an access fee land dynamically or statically. Now I will say switch poor access villain. And this is saying which villain to tag user age traffic as by default access. More ports are assigned to villain one. So if we didn't actually specify on access, feeling I d here than the port would assign all ingress traffic two billion won and you really don't want to use villain one. It's really not a best practice, and it's typically going to be on unused villian as we have mentioned before. We want to use the land, too, so I'll say so. It's poor access. Be lend to by Ron Do Show Ron interface after one size ears is 13. Let me get rid of some of these other commands here. I should have defaulted the interface. We're gonna change the description on this to user A Let me run. She'll run on this interface again. So now we can see that I told the interface I wanted it to be an access mode and to use access to be land to just for some more practice, we'll go ahead and configure. User sees poor as well on this switch. One good thing to do if you were starting a new configuration on a port that has nothing connected to it and you want to just start fresh on an interface because you look at some of my other interfaces. I have all of this configuration on them and instead of going to the interface and selecting each command and saying no and removing these parameters, you can actually just default on interface like this so that it puts the interface back to its default configuration. Makes it a little easier for then you know that there's not any configuration. Just hang your own on any of your interfaces as well. So now you see that I have, ah, bear configuration here. So we'll go to that interface configuration mode. Say description, user. See switch poor. Switch port mode access and then switch poor access. Villain three. I already had Guillain three pre configured I d three and that's my server mansion be land just to show you something. I'm gonna stray away from our diagram here. And what I'll do is I'm gonna change this to B vineland 33 just because I don't want to remove the line three for this example and I want to show you an important thing to know about configuring access mode ports. So you already know that you have to have the villain configured in the villain database here. Four of the villain to be actively switched on your switches. One cool things that switches will do for you. As if I had a feeling that I didn't have my database like 33. You can see Bill and I d 33 not found in current villain database. Well, if I wanted to configure an access feeling for, for that the land just by creating the villain, I'm sorry. Just by configuring the access bill in port, the switch will be kind enough to actually create the villain in the villain database for me. So let's go ahead and do that and you can see that it tells you access villain does not exist, creating villain 33 and it's going to just give it the default. The land name of Be lan 00 33. So I didn't even have to remember to add the villain. It just did it for me. It's the switch. Looks at it as you're adding on edge poor around this villain, you obviously are gonna want the villain created globally, so all created for you. So now we know how to configure a basic access violin import. Well, what if you had a phone in between your end point in your switch? It is very common on networks to have a phone connected to the switch and then your PC plugged into the phone instead of running to cables won for the phone and one for the PC phones actually can act as a basic switch so that you can have a single cable drop to a desk, but still be able to connect your phone and your computer. Now you can let your phone in your computer just land on the same access feelin. But bus practice would be to segment your voice and data traffic with different villians. To accomplish this type of configuration, we're still gonna configure our Access V Land port for the PCS traffic, just like we would even if the phone was not in between the switch and the PC. Because the PC traffic is just going to be passed right through the phone to the switch where it's going to land on the access Villain in this example would be villain, too. For the phone. However, we're going to configure a voice villain on the switch port, and the switch will actually inform the phone off which villain to tag. It's traffic with via CDP. So the switch sends a CVP message to the phone telling it to tag. It's traffic on Bill and three, and then when the phone son's voice traffic out. It will use Villain three as a tag. Then the switch can tell the difference between the data traffic coming from the PC and the voice traffic coming from the phone. Now we'll jump into the lab to configure a voice villain port. Okay, here we are in the lab switch. Will you show CDP neighbor to see where our phone is connected? We have a Cisco phone connected on Port 20 here. Can see it's an I P phone. Another cool way you could find out if he had a phone connected. Would be seeing what was drawing power. So, peewee power. I can see that when I run the command show power in line. I have a Cisco Access point connected on Port 19 drawing 15.4 watts of power. And then I have this 79 40 Cisco Happy phone drawing 6.3 watts. So let's take a look at the current configuration for our port with the phone connected. It has the description of a phone that I previously configured, and you can see that we only have the switch port and mode access and then access feel and 10 so In theory, the phone should be getting an I p from Ville. Anton Floats, Ron Show CDP Neighbor four Interface 20 and they will say detail. And sure enough, we can see that the phone is on Villain 10 which is our data villain so you can see wire data and we wanted to be on, I believe, 14. So 14 is our wired voice feeling. So that's where we want the voice traffic to be on to show you something cool. I actually have logged into the gooey off the phone. And if we go to network configuration, you see this operation of the land I d. Value here is blank. So sensitive Blank The switchboard is just seeing UnTech traffic come in and then throwing it on the access villain villain, which is villain 10 in this case. So when we configure voice villain will come back in here, we'll see that we have the operational villain. I d reflect the voice villain i d configuration. Okay, so we'll go to our ports configuration and we're simply going to say switch poor voice villain and then just the villain i d. So we'll save the land. 14. Since That's our voice, the land, And you'll see that if you do show CDP neighbor for that port that it still has this I p on villain time and it doesn't know what attack its traffic yet. So what you want to dio when you make changes like we just made to a voice port and we're just gonna shut and then no, shut the port that will make the phone reboot sense. It's receiving power from this port. When I shut it down, it stops receiving peewee power and that it's gonna reboot now and then when it boots back up, it should come up and start using the voice villain that we just assigned via the Swissport Voice villain command here. So I'm in patients. I'm going to keep refreshing the information for the sport. Okay, so it looks like our phone finally got an I p address and you'll notice that it's on the sub net 10.0 dot 14 which if we look at the FBI for viewing 14 we can see that we're now on the correct a villain. So we know that our voice ballin worked, But just to prove it to you will log into the phones gooey and we'll go to now we're configuration and you can see now that it's operational villain ideas 14. And I can promise you that I did not log into the phone and configure that it it learned the villain idea via CVP and is now operational on our voice villain. One more thing to mention about configuring a port for voice while we're on the topic. You'll also want to configure your qs. So I would say best practice for a Cisco phone would be to say Awlaki was VoIP and then Cisco Phone and it'll configure boy qs If there's a Siskel phone attached the port. And don't be worried when you enter the command, it will pause for a minute cause it's configuring, Semak rose in the background. But now, if we look at the sport again, that is the typical configuration you'll see for having a phone with a computer plugged into the back of it. 3. Trunk Configuration: now that our edge ports are configured in access mode with our access. Villains will now configure our trunk poor between our two switches. So our edge porter configured over and switch one. Let's configure our transport. Now we're going to use interface once last year old slash one. Put in Switzer Port mode to make it a layer to port. And then we're in this waste say, Swissport mode and then trunk. This is one way to configure our trunk ports, fire on do Show interface, the interface number and then the keyword trunk it's going to give us are trucking status. For that interface, we can see our motors on. Our encapsulation is 802.1 Q Status trunk ing and native villain one. This will be a good time to go over the different modes encapsulation zones and to talk about what a native villain is. A native villain is an antagonist villain across a trunk link. For instance, if we had let me add another user over here to make this example a little bit easier to explain, and then over here will have user AF and they're also going to be in villain for if we can figure this trunk port to allow billions to four and 33 across the trunk port with that one . Q. By default, there's a native villain and Anita villain is really just saying when I send this veal end information across this trunk port, which villain am I gonna send without a V land tag by default? Villain one is gonna be your native Dilan. So if we just plugged the switches in and configure them as Trump Ports villain, one would be the only on tag villain going across this trunk port. You can actually apply a global configuration command that will tag all of the lands so that you don't necessarily have to. You use the need of the land, even if it's the default for a specific trunk ing encapsulation. A good thing to understand about native lands is just because I have a specific villain as my need. A villain across my trunk Link doesn't mean the traffics not going to get from point A to point B. For instance, if I made my need a villain on this trunk port to be a V land for and veal and four traffic comes in this access mode port The switch? No, Was that its billing for traffic? And if it had a layer to entry across this link, it needed to send traffic across That is going to send it without it to be land tag information. But once it arrives on this side, this switch doesn't know what traffic is entering this port on tag. But if it happens to have the same native Ilin configured so that both sides have feeling for as a native villain, it's going Teoh intercept that traffic on the ingress and send it out whichever veal in it was using as its native villain. So if I happen to use native villain to right here and then I used need a villain four on this side, then traffic coming in. His villain four would be sent out on tagged and then be sucked into bill into on this side . So you definitely want to make sure you're needed villain matches on both sides so that whenever traffic happens to be the antagonist, traffic going across your trump port matches up so you can get things from point A to point B. Now that we've talked about and explain. Need TV Land's Let's go ahead and configure our need a villain on our trunk port between these two devices. As you can see here, it's native villain won by default. I like to keep the need of the lan as an unused villain. So what I'll do is I'll create a villain that I'm not using for anything, and we'll call it our native the land. I usually just keep it as villain one, To be honest, I mean, most networks that work on just have a feeling one, because it's easier for deployment. And if you don't use veal and one for anything, cause that another best practices not using dealing one. So if you don't use villain one for anything and then use it as your native villain, you're kind of killing two birds with one stone because one of the need a villain Best Practices is to use an unused villain. And since it's villain won by default, it kind of makes it easy on yourself. Just don't use Villain one, and then your default need a villain on your trunks is one, and it's an unused 1,000,000,000. But of course, as I mentioned. It's best practice to use a veal and other than dealing one as you need to be land. So depending on how secure you're trying to make your layer to, nowhere is the deciding factor for what you use for your native dealing. But for this example to follow the most best practice method will create a essentially a black hole villain that we're not gonna have anything on, and we'll call it native the land. Do you show run in her face? Affluence? That's years. That's one. So we have as a trunk poor. Let's change our native the Lanham of Switch Port Trunk, native villain and then the villain idea of 200. We'll look at our trunk port to make sure the native Dylan was accepted, and we see that our need a villain is now 200 on that switch port. Now let's talk about different trunk ing encapsulation ins. The two different villain trunk encapsulation is you can use our I s all inter switch link encapsulation and 802.1 Q also known as just 0.1 Q I s l is a Cisco proprietary protocol, and it does not support need to villains. So now that you know what I need a villain is if you configure it. I s all trunk between your two switches, all the lambs would be tagged and there would be no contact. The lands traversing that trunk. One of the key differences between isil and 10.1 Q is how the V land tag is handled. I s l encapsulate its the Ethernet frame with the I S l villain Hatter. And that one Q just inserts the villain header into an existing Ethernet frame. 802.1 q is actually a standard protocol, So it's definitely the more widely used protocol. And actually, I s Al isn't even supported on most newer switches all newer switches and after the slide will configure encapsulation since I have some Lord older switches in the lab. But it just good to know that by default. Now switch Trump ports are 0.1 Q and you don't even have the ability to configure them as an I SL trunk port. And, of course, that one Q supports native villains like the trunk port we just configured. For example, I had it configured as a 0.1 Q encapsulated trunk. So we were able Teoh configure the native villain. In our example, we've seen how to verify what are encapsulation were using. Let's also run our switch Port Verification Command and you can also see by running this the show interface switchboard command of what your administrative trunk encapsulation is as well as your operational To change the encapsulation you're gonna say Swissport trunk encapsulation and will run question mark. And you can see that one Q i s l or negotiate 0.1 q would be statically configuring the poor to use 0.1 q encapsulation I s o would make it use I s l on The negotiate would give the trucking port the ability to negotiate which encapsulation it wanted to use between the two switches. We're gonna go ahead and use 0.1 Q as our trunk encapsulation. One more check with showing her face trunk and we can see we're using our 802.1 q encapsulation. Next. We'll talk about modes and we have trunk negotiation modes dynamic, desirable, dynamic auto trunk and I negotiate each of these modes our different ways. You can configure your trump ports some of these modes use DTP or dynamic trucking protocol . DTP is just a protocol that gives switches the ability to negotiate a trunk port. How DTP works when you plug two switches in and they have connectivity between each other. If DTP messages air turned on, then DTP will be sent between the switches, and they will attempt to negotiate. If they want Teoh form a trunk port between each other to successfully bring up a trunk connection. You have to have the right modes configured on each side that I'm a desirable actively attempts to negotiate a trunk dynamic auto passively will attempt to negotiate a trunk trunk will always be a trunk. Now negotiate never negotiates a trunk. If we look at this compatibility table, you can see which modes will form a trunk between each other. Trunk and trunk will form a trunk trunk and dynamic auto and desirable will form a trunk. Basically, every different mode can form a trunk between each other except auto and auto. And since you can imagine since on oh is passive, there's no way for too passive interfaces to negotiate a trunk, so they would just stay at the default of access mode if you had to auto interfaces connected to each other. Now I'll show you how to configure each of the different trunk ing modes on your trunk interfaces. You would configure your port switch support mode and then if we just said trunk, that would be the mode on so sweet support mode. Trunk would be the always negotiates a trunk trunk mode. That is the preferred method. You It's ah, security. Best practice to not negotiate any of your interfaces. So just by doing sweet support mo trunk, you're saying I'm just going to do a trunk? I don't care what your site is. I'm gonna be a trunk. You will still send DTP messages out that trump port. But it will just always be a trunk. If we want Teoh use a negotiation method. We can say dynamic question mark and then desirable or auto Looking back at the slide, desirable will negotiate a trunk and then again on oh well, passively. Just sit there and wait to receive a DTP message for the other side to tell it. Hey, I wanna negotiate a trump or see switch port, not negotiate. So this command it isn't really a mode. It's really just turning off DTP. So it says right here device will not engage in negotiation protocol on the center face, and this would be used with the mod trunk Come in. So I could say, I want to be a trunk and I do not want to negotiate, So I don't want the other side to receive any DTP messages from me. I want the other side Teoh be Amo trunk and just beyond, and no DTP messages will be sent back and forth. I'm going to remove this because for this example, I want to configure dynamic, desirable and the dynamic auto on the other side. I normally would configure just mowed trunk, but just for this example will use dynamic, desirable on auto between these two switches. So what's a mode dynamic and we'll do desirable on this side, and then we'll do auto on the other side over here. So now I'm over on, switched to first. I'll confirm which interface I need to configure the trunk port on with show of CDP. Neighbor have to connections to switch one, but I know that it's port one. That should be used for the trunk port, so we'll go toe support one. It's not a new civil defaulted start from scratch. Make sure it's switch port. I know that our native land on the other side is 200 so we'll make that match. This is an older switch, so I have to identify the trunk encapsulation and then I'll say, switch port mode dynamic. And on this side, we decided to do auto. Looks like we successfully negotiated a trunk. We'll jump back to switch one. We'll verify our trunk ing status one more time. We're using mo desirable for actively using the dynamic trucking protocol negotiations. 802.1 q Encapsulation status. Trunk ing need a villain? 200. Next we see what villains are allowed on the trunk. By default, you can see that every possible villain is allowed. The ones that are allowed inactive in the management domain are the ones that we're going to have actually configured on our switch. And then we have the ones that air the lands in the Spanish affording state. This is what we really care about. We want to see the villains they're actually fording are the ones that air listed here in the Bill Lann Spanish affording state 4. Trunk Pruning: drunk Pruning is an important concept to understand when you're configuring trunk ports. The purpose of trunk pruning is to prevent unwanted villain traffic from being flooded out of your trunk ports, for example, Let's say in this topology here we added the land for off of Switz one, but switched to did not contain any users on villain for well by default. Trunk ports are going Teoh allow all the land traffic across that port, So imagine the feeling forward to send any broadcasts. Those broadcasts would go all the way across the trunk link between switch one and switch to, even though switched to does not contain any hosts on Villain for so obviously, there's no reason for that traffic to be flooded across that trunk port. So with drunk pruning, we can actually define what villains are allowed to go across our trunk ports. So in this topology, we would want to say on Levi lands two and three can go across this trunk port because there's no reason for any other be lands to go between these switches with this type of configuration. If Villain four did send out any broadcasts, the trunk port would not for that traffic out of that trunk. And then we have on optimized land without any unnecessary traffic flowing between our switches. So I don't care if it's ah, another switch or ah bm host server. You always want to try and prove your villains to Onley the villains that are going to be utilized on that specific port back in our lab. Switch here to configure some trunk pruning. First, I want to show you what the interface output looks like before we configure the trunk pruning. So we'll say show in her face and then trunk. So here you can see that by default my he lands that are allowed on the trunk. Poor are all the lambs one through 4094 and then you you see what the lines are actually 14 based on what the lens I've configured and spanning tree. But this is what we're going to focus on for this example. So this sport is connected to another switch in the lab. And let's say that the only villains that I have configured on the other side of the switch our villains two through six, then to only allow billions two through six across this trunk port will go under the interfaces configuration mode. I'm going to type switch, poor trunk allowed, villain. And let's do question mark here so you can see all the different options. I could just define the vehicle and ideas that I want to allow on this poor, which for our case here, Since we don't have any other villains defined or prune, then that's fine. So we would just say to we could use commas if he wanted. But since I have ah specific range here, we can say to hyphen six they Now if we go back here and run our one port command again now you can see that Onley Villains two through six are allowed on that trunk port. So that's exactly what we want. Now I'm gonna show you a lesson for the real world that will really come in handy. I'm gonna show you one of the biggest mistakes network guys make. And I personally, even though I know that I still make it once in a while, but pay attention if you're dozing off, Now is the time, Teoh, pay attention. All right, so let's go back, Teoh that command here and see what our options are. It's a vital question, Mark. You can see you can dio what we did and just defined the villains you want in the trunk port. You can add the lands to your existing list. You can say all so like, for example, here I I've only defined some I could see all. And then it would change this to B all of the lands. Or I can say all villains, Except for then the villains I define. You can say non. Maybe you're in a test phase and you don't want affordable and traffic across your sweet support. Yet you could say none and then you have remove. Okay, so the main one you want to remember his ad and then second to that would be removed. And I'm gonna tell you why. So let's say that you're you start a new network job and your boss says, Hey, we have these servers connections that were trunk into the servers and the there's gonna be a new VM farm and they're going to use the land. Let's say seven so and so you have to your tasked with adding veal and seven to this trunk allowed list. Now the first thing you're gonna want to dio is you're gonna think, Oh, I'll just say, switch support. Trunk allowed the land seven and then all of a sudden there's gonna be that moment of silence and then there's gonna be phones ringing. And then there's going to be some panicking Boss is coming over to your cube because if you just say such for trunk allowed the line seven. That's saying you're only allowing that one villain across that trunk poor so you can see how now we've changed our allowed list to Onley be that villain. You think that? You know, each time you configure a villain with this command, you're just a pending to your existing list. Well, that's not the case. You're just wiping out. So let's put what's put back our old configuration and I'll show you the right way to do that. I just calls that apology change there. Okay, so let's go back to question mark. So if you're just gonna add the lands to a current list and that those currently lands are going to stay there, which is almost always the case, you're gonna want to say add and then the villain. So now when we look at our list, it will have just added that be land to it instead of redoing the whole less so that is so important. And in fact, still to this day, every time I have to do this, I'm so paranoid that I do the ADC you were, and I sit there and stare at it like OK, did I do that? Keyword. It's so crucial to remember that and maybe even write out your script and no pad. You know, before you actually configure the poorest, you don't accidentally miss. Configure it. Okay, so that's how you add a view into a port. Now let's say that you wanted to just let's say that Ah, you know, they you're getting rid of a villain. You maybe you have consolidated some servers and you no longer need veal and seven on that poor because you're trying to clean things up. So to do that, you could just use usually remove keyword, and I could say, remove villain seven. So now I want to look at that port. You can see it's back to our two through six list so add remove. I know it sounds simple, but you'd be amazed at how often we can overlook that. Now, Another way you could do it. I mean, you could just like, Let's go back to Let's add seven back on So sevens back there. I mean, you could in this case, if you're just removing, you could just re add two through six like that. But I don't like that. The the add remove keywords are there for a reason, so make sure you use them.