Okay, so let's talk about VLANs some more. So next, we're going to get in and understand VLANs in more detail, so you'll know how to work with them. You'll understand how to set them up, how they work in their internals and things like that. So let's get to zoom in to understand them in more detail. So here's a sample network. You've got your switches, you got your host. So when you've worked with VLANs, it's important to remember ports. Because when you set up VLANs, it's all about ports. It's all about logging in to the switch and telling ports what to do. Ports are the physical interfaces on the switches. There's two kinds ports, there's ports that face your devices, face your IoT devices, face your access points, face your computers. These are called access ports on the switches. They're ports that are used for access into the network. Then there's also trunk ports. So trunk ports are ports that are used to communicate between switches, so switches can talk to each other. This matters for VLANs. So if I set up VLANs, maybe I'm going to set up some VLANs between these different devices, what I'm going to do is I'm going to go into my switches and I'm going to configure my ports as being either access ports or trunk ports. Because the switches don't know. I mean the switches don't know if a port is connected to an IoT device or another switch, you have to tell it. So you go into the command console and you type in commands, there's commands for this. Then you configure your VLANs to be on these different ports. So what access ports do is they pin tags to packets. Because we don't trust in host with VLANs. Another way we could have implemented VLANs, is we could have said. Okay, each device is going to create Ethernet packets and it's going to say what VLAN it's on. But that's not very secure, because you don't trust who comes in your network. You're going to have guest users coming in, you're going to have insecure IoT devices. So the way you should set up VLANs is you're going establish a perimeter for your network and you're going to have a set of access ports. That's going to be your perimeter. Your access ports are going to pin tags to packets. So in host are going to send regular Ethernet packets without a tag, your access ports are going to take them in and you're going to statically configure that access port to be on a certain VLAN, it's going to pin the packet. Because otherwise, a host could walk up and pretend to be on your credit card network and what could you do? So the access ports are pin tags to packets, whereas the trunk ports are sitting there, and the trunk ports allow communication between switches. So trunk ports are different, trunk ports are used for transport, so they can multiplex multiple VLANs. You can see that in this figure. Each host is on it's own VLAN, but the trunk ports have to be able to send traffic for multiple VLANs at the same time. So you could do that with trunk ports. You can login and you can say; okay, this trunk port is going to be able to transport VLANs one, three, and seven. So you can do that. But access ports only are configured for a single VLAN. VLAN membership is something that's encoded statically. You log into the switch and you configure it and its set. You might change it, if you disconnect the host and plug it back in. But it's not something that changes very dynamically. You do that by going to the switches configuration file and editing it. To understand VLANs, it helps to kind of look under the hood and understand how they're implemented. What I'm going to do now is I'm going to show you the Ethernet header. I showed you cartoon versions of the Ethernet header before where we have the source MAC address and destination MAC address. You've seen that before, those are in the Ethernet header. But there's a few other fields too, I want to tell you about. So this is the real Ethernet header from the actual specification. One other field I want to tell you about is something called the EtherType. So if you think about it, a host is sitting there and it gets an Ethernet frame that comes in and it sees a source destination MAC address. That's great and it sees some data. What's going to take that data, is going to send it up into the operating system. Where's it going to send it to? It doesn't know what the data is, maybe the data is an IP packet, maybe it's some other kind of protocol running on top. So what we need in layer two, is the ability to demultiplex these packets up into the operating system. That's accomplished by the EtherType field. The EtherType field is a field that denotes the type of data contained in the packet. You're going to see this over and over in protocols. The IP header contains a field as well to tell you what protocol is above a TCP or UDP and so on. So at layer two, this is how we do it. There's the EtherType field. So this is a Ethernet packet. When VLANs came about, they had to figure out a way to introduce them into Ethernet. Because VLANs weren't always a part of Ethernet. A long time ago, there was just Ethernet. Then they invented this idea of having VLANs and they figured it was a good idea. They wanted to put them in Ethernet and they had some choices to make. One choice could have been, Ethernet 1.0 is out there, let's throw it away. Let's introduce new version, Ethernet 2.0, which has this additional header in i. T which is the VLAN ID. They could have done that, but they didn't want to do that because that would make it harder to deploy. If I have a network with a bunch of switches out here already, which support regular Ethernet and you're coming along, you're telling me. Okay, I can have VLANs but I got to throw away all my switches. That's a huge investment, that's going to cost me a lot of money. It's better in protocol design to design protocols that are backwards compatible. You see this over and over in protocol design. You'll see all these things, with the IP specification and other things. Where there's all these fields and you wonder, why are these fields in there. Well, some of that's there for backwards compatibility. Because it's hard to introduce new protocols. So you see that here with VLANs as well. So with VLANs, what they did is they did something clever. They shimmied in another header into the Ethernet frame. We'll talk about how they did that. So first of all, with VLANs, you need some way to identify them. In the example I showed you before, there's payment card Infrastructure network, HFAC network. We could identify VLANs with text strings. But it's kind of hard to put a big text string in a packet. So instead VLANs are identified with numbers. Then you kind of remember which numbers are which, what type of VLAN. How big should these numbers be? Its a question of how many VLANs you want to support. If you have a typical network, how many VLANs you're going to need. So that tells you how many bits we should set aside. This is a question that comes up over and over in protocol design. You have a field, you got to assign, figure how many bits you need. This famously happened with IPv4. They decided to have 32 bits, which made a lot of sense at the time. It was probably a good decision to make at the time. But in retrospect, it would have been nicer if they put more bits in the header. So anyway, this issue comes up with VLAN tags as well. So with the original VLAN specification, they decided that packets are going to be annotated with 12 bit VLAN tags. So we're going to add another field to the header, which is the VLAN tag or the VLAN ID is going to be 12 bits. So that limits the number of VLANs you can support. This is all defined in the VLAN specification. The agency that owns VLANs, that controls the VLAN specification is IEEE. It wasn't invented by the IEEE per se, there was a person who invented it, in a set of people. But you don't have a person to control a specification, you want to hand that off to an agency to kind of be in control of it because the agency can kind of follow rules about how they update things. It gives vendors trust. The vendors trust the IEEE to do a good job with specifications. So the IEEE controls the VLAN specification. If you want to look up the documents that define VLANs, you look up 802.1Q. Because IEEE has numbers to number its documents and that's kind of the format of the numbers. The 802.1Q is the IEEE specification for VLANs. So if we have 12 bits that limits us to 4,096 VLANs or two to the 12th. That can be encapsulated with a single VLAN ID. I also want to point out 802.1Q specification is not just about bits, it's not just about VLAN tags. There's a few other headers that puts in there too just so you know about them. First of all, there's this question of how you kind of shimmy in this additional header. What they did was something that's kind of clever. What they said is, there's this EtherType field which denotes what's in the data packet, whether it's an IP packet or whatever. So what they said is, "We'll just have a special EtherType field that tells us actually that data that's coming up, that's not just data, that's another header. That's a VLAN header." So if you see this particular EtherType and they chose 0x8100 for that value. If a switch sees that, it's going to say, "Oh, what comes after this is not data, it's actually something I should look into, its a VLAN header that follows this structure." So they use EtherType to piggyback in this additional header. So an EtherType of 0x8100 instructs the switch to decode the next two bytes as a VLAN header. That's how they kind of did this in a backwards compatible way. Because if you have a switch that doesn't understand VLANs, it'll take in this packet, it'll look at the EtherType, it'll say, "Oh, I don't know what that means." It'll just forward. So it will still be correct. It just won't support VLANs. There's also a priority field that gives three bits of priority. Similar to IP type of service, if you happen to know what that is. There's one bit for compatibility with token ring. So there's a few other bits and their use for some other stuff, like quality of service. So with VLANs, there's this question of, are 4,096 VLANs enough? You'd think it would be. I mean, if you have a physical network, are you really going to have several thousand VLANs on one network? For many years it was enough, I mean, VLANs came up back in the 80s and that was plenty for back then. But then the late 90s data centers really started taking off and Peel started building these huge layer two infrastructures and 4,096 VLANs just wasn't enough. So the IEEE kind of sat down and said, "Okay. Well we need more headers. So we could just extend the 12 bits to be more bits, then become the simplest lowest complexity way to do it." But then again, the IEEE likes to be really backwards compatible. Which is good and bad. I mean it kind of makes the protocols a little bit more complex. But the advantage is that, these protocols get really deployable, you don't have to throw your existing hardware. So what the IEEE did is they had developed another specification called 802.1ad which is sometimes called QinQ encapsulation for short. Because it's like 802.1Q inside of 802.1Q is how they do it. So it's like QinQ is like a cute name that people use. The way it works is you encapsulate VLANs within other VLANs by stacking these tags. Like having a tag and then another tag one after another. So with that, you can have many more VLANs. You can have two tags which will give you 4,096 squared combinations which is a lot more. So that's powerful. So when you go out and you buy switches, you can kind of look at the switch and look through its data sheet and the switch will tell you, oh, it supports the 802.1Q, it supports the 802.1ad. So you could think about what you need when you purchase switches. You might look at this stuff and you might say, "Do we really need these stuff and protocols anymore?" I mean pretty much any switch you buy today supports VLANs. Is the IEEE being silly? I mean, they're still in the specification, this ability to kind of support older VLANs, and that's kind of an interesting question. So the answer is, the IEEE still supports this. It supports the ability to create networks that don't have VLANs and connect them together with networks that do have VLANs. So there's one other concept I want to tell you about, and that's the notion of a native mode for VLAN. The way this works is the IEEE recognized that you have these networks and you might have networks where part of it supports VLANs and part of it doesn't, and so how do you connect these things together? I mean, what does it mean for a network packet to come in that's not on a VLAN. How do your VLAN enabled switches treat it? If you have a policy that says "Packets from this VLAN have higher priority than this VLAN", how do you treat non-VLAN packets in your configuration file? So the way switch vendors and IEEE kind of do this is they say,"We're going to treat non-VLAN packets as actually being on a VLAN. We're going to have the notion of a special VLAN called a native VLAN for non-VLAN packets." This is what native motive is. So the IEEE likes to make specifications that are very backwards compatible. So 802.1Q, when it was defined, allows trunk port security both tagged and untagged frames. Frames with no tags are said to be part of the switches needed in VLAN. You could argue about whether this is the right way to do things or not. But one powerful thing about this is, it makes switch configuration easier to do. Because then you can define policies based on VLANs, and if you have untagged packets, well, that's just another kind of VLANs. You are going to apply your policy to the native VLAN which is the VLAN with native packets. In practice, you might not use native VLANs because you probably have networks that where all the switches run VLANs. Pretty much every switch you buy today can support VLAN. So you probably want to steer away from native VLANs in practice, but if you encounter a network where there are native VLANs, this is how you deal with it. You have to be careful about it because native VLANs, there are some security issues with these. There's something called VLAN hopping where you can kind of send a packet and tunnel it through a native VLAN and cause it to hop into a VLAN. So you have to be careful how you configure your networks with native mode. So if you can, try and steer away from using native mode, but if you do have to use native mode, be very careful about establishing a perimeter and making sure all of your ports have packets go on a VLAN before they go into a VLAN enabled part of your network.
