OECG – Chapter 2 “Virtual LANs and VLAN Trunking”

Good review of all the basics here: VLAN’s, starring DTP, 802.1q, ISL, tags, private VLAN’s, and more. Not a terribly long chapter, but good fundamentals to know.

• Definition of a VLAN – a group of ports that can span multiple devices, but are still a part of the same broadcast domain.
• Usually, you have a VLAN pair up with a subnet. In other words, it’s customary to run a single IP network. It’s possible to have a single router interface with secondary addresses route between subnets contained within the same VLAN, but I’ll tell your Mom if you do that. Naughty!
• Layer 2 switches don’t forward frames between VLAN’s. That’d be the job of a multilayer switch (MLS) or a router.
• (Total aside. I’m using Firefox, and it’s checking my spelling as I type. You know how many acronyms and abbreviations I’ve had to add to my dictionary??)
• There’s 2 different modes you can use to create VLAN’s: VLAN database configuration mode, or regular configuration mode (you know, where you do everything else). Although the book doesn’t really mention it, VLAN database mode is going away AFAIK. I haven’t tried VLAN database mode in quite a while. Even so, I believe on a newer switch like a 3750, IOS is going to pat you on the head for being so cute, but still direct you to regular config mode to do your VLAN work. IOW, the deprecation man cometh.
• Note that if you’re using VTP, you don’t have to configure the VLAN’s on every switch, but more on that later.
• There’s quite a bit of talk about how to do business in VLAN database mode, so I assume I need to know it for the test. It feels vaguely like practicing how to install a landau roof on the ’06 Porsche Cayman I don’t own, but I can do what I’m told. So…from the # prompt (not config), you type “vlan database” to get into VLAN database configuration mode. To create a VLAN, type “vlan 23” where 23 is the number of the VLAN. Then “show current” will show you what’s active in the VLAN database (or “show current 23” if you wanted to see specifics about VLAN 23). Newly created VLAN’s won’t be there – do a “show proposed” if you’re all in a hurry. To make that newly created VLAN active, you can “apply” or “abort” if you’re getting scared and bail back to the # prompt. Or “reset” if you’re only sort of scared and want to wipe out the newly created VLAN’s, but stay in VLAN database config mode.
• To put an interface into a VLAN, “switchport access vlan 23”. To check what interfaces are in a VLAN, you could “show vlan brief” (or “show interface status”, my personal favorite.)
• Now on to the way all the cool kids make VLAN’s. We use regular config mode. Hooray! There’s a couple of ways to go about VLAN creation here. One way is to “vlan 23”, which creates the VLAN and drops you into “config-vlan” mode (while you’re there, use “name My-Cool-VLAN” to give it a name). The other way is from an interface config paragraph, do a “switchport access vlan 23”, which will automagically create the VLAN for you if it isn’t there already.
• On to private VLAN’s. The point of private VLAN’s is to allow you to have a whole bunch of hosts in the same IP subnet, but limit their ability to communicate with one another. Private VLAN’s are an on or off situation – when you use them, either devices will be able to talk to devices completely, or not at all. This isn’t like an ACL or filter. Private VLAN’s offer a primary VLAN that you define as private. The primary VLAN has your promiscuous ports – devices that should be accessible to everyone in the VLAN. Think servers and layer 3 gateways. Secondary VLAN’s are either isolated or community. Now, isolated VLAN’s and community VLAN’s have unique VLAN numbers, but think of them as hierarchically subservient to the primary VLAN. Isolated VLAN’s contain ports that can only talk to promiscuous ports. Community VLAN’s contain ports that can talk to other ports in the same community and promiscuous ports, but not to isolated ports or ports in other communities. Private VLAN’s can span multiple switches across trunks, since the VLAN numbers are unique (the book doesn’t mention this, but I thought I’d throw it in there.)  Special note – private VLANs require that the switch be in vtp transparent mode.
• And now VTP (VLAN trunking protocol), a useful yet feared protocol. Useful because all switches that are a part of the VLAN domain learn about new VLAN numbers from a VLAN server. You create a VLAN on a VLAN server, and everyone else in the domain knows about the VLAN. Nice if you have 100 switches in a domain and want all the switches to know about every single VLAN you create (which is doubtful, but convenient nonetheless.) Feared because VTP isn’t terribly careful about who gets to send out updates. All you have to be is a server. So if you manage to put a switch on the network configured as a VTP server with the same domain and a higher VLAN database revision number than any of the other VTP servers in the domain and uplink it with a trunk (oh, and configure it with the same password if you’re using one), everyone will get a copy of the VLAN database on your shiny new switch. So if the only VLAN you had created was, say, “1”, you just hosed every switch in your VTP domain. VLAN databases update in their entirety – everyone gets an exact copy of what’s on the VTP server. So if the only VLAN the VTP server with the highest revision number is serving up is “1”, then all the other VTP domain members will wipe out every VLAN in their database except for “1”. A possible suicide moment for a data center, with no easy path to recovery.
• Okay, enough VTP overview. How’s it work? Well, you configure a switch to run in 1 of 3 different VTP modes: server (default), client or transparent. Servers send out VTP advertisements periodically. Servers and clients both read through the advertisements and make updates from those advertisements. Transparent mode switches just forward VTP advertisements on, but those advertisements have no local significance. Here’s another big point. Clients do NOT save VLAN data in NVRAM or in VLAN.DAT. Servers and transparent mode clients both save VLAN data locally. Also, you can’t create a VLAN on a VTP client (makes sense, what would be the point?) You can create a VLAN on a VTP server or a switch in VTP transparent mode. When you create a VLAN on a VTP server, the VTP server increases the VTP revision number by 1, then advertises the new database, including the revision number. The revision number is the trigger that tells the switches whether their VLAN database is current or not.
• If you’re throwing a VTP client on the wire, you can pretty much do it with reckless abandon. VTP clients don’t send out VTP advertisements (heck, even servers will only advertise if you configured a domain, and then only across trunk links), so there’s no risk of hosing your network up. If you do the “vtp mode client” statement, that’s all you need. If you don’t configure a VTP domain also, the VTP client will add itself to the domain of the first VTP advertisement that it sees. That’s fine if you only have the one VTP domain, bad if you have more than one running, just pay attention.
• If you configure a VTP password, be aware that the password is encrypted in the VTP advertisement with an MD5 hash to foil the sniffer beasties.
• Trivia – CatOS (You remember CatOS don’t you? Admit it…some of us are still running it here and there.) also offers VTP “off” mode, where VTP advertisements are not only locally ignored, but also dropped (i.e. not forwarded).
• There’s several commands to know involving VTP, pretty self-apparent, especially if you’ve executed them a few times before. “vtp domain MySweetVTPDomain”, “vtp password MyPassword”, “vtp mode client|transparent|server”, “vtp version 1|2” where clients and servers must be on the same version to exchange info, “vtp pruning” in which broadcasts are peeled off of trunks for VLAN’s that haven’t been configured on any ports on the far side of the trunk, “vtp interface” where you can tell VTP what interface to source the MAC from for VTP advertisements.
• Yikes. This is getting long. Soldiering on…
• VLAN numbers fall within a couple of ranges. VLAN’s 1 – 1005 are considered “normal range”. VLAN’s 1006 – 4094 are considered “extended range”. In the way-back machine, only 802.1q trunks supported extended VLAN’s. ISL only used 10 bits for this, while 802.1q used 12 bits. ISL was later updated to the same 12 bits to support extended VLAN’s.
• Some special VLAN numbers: 0 – reserved, can’t use it; 1 – normal, can’t be pruned, can’t be deleted or changed; 2-1001 normal; 1002-1005 normal, can’t be pruned and is used specifically for FDDI and token ring translational bridging (cause we all need a little token ring in our lives); 1006 – 4094 extended, plus you CAN’T advertise or prune these across VTP.
• More on normal vs. extended. VTP servers can’t make use of extended VLAN’s (implicitly then, you’ll never see an extended VLAN on a VTP client, either). VTP transparent mode then, is the only place you can use extended VLAN’s. And you’ll do it from good ol’ config mode, because VLAN database mode doesn’t support extended VLAN’s. Oh, and you’ll store that extended VLAN info in running config. VLAN.DAT in flash is for normal VLAN’s only.
• Trivia – if a switch reloads, the switch will only use the VLAN data in VLAN.DAT if the VLAN.DAT and startup-config differ.
• More trivia – if you’re on a CatOS box trying to delete the VLAN database, you need to delete VLAN.DAT from flash…from ALL VTP servers…BEFORE reloading the switch (otherwise, it’ll just learn it all again from a remaining VTP server when it comes back up.)
• On to trunking. A trunk is a inter-switch connection that carries multiple VLAN’s. It accomplishes this by either encapsulating (ISL) or tagging (802.1q) an ethernet frame with VLAN information. ISL adds a 26-byte header and new trailer (to accommodate the new FCS value). 802.1q sticks a 4-byte header (a tag) into the original ethernet frame, right after the source address. Usually, you’d see the Ethernet type field or 802.3 length field in that spot. However, when 802.1q sticks the tag in there, the first 2 bytes of the tag are 0x8100, telling the ethernet device that what it just found was a dot1q tag.
• Native VLAN’s on trunk lines. In dot1q land, the native VLAN (VLAN 1 by default) doesn’t get tagged. ISL doesn’t support a native VLAN.
• DTP is Dynamic Trunking Protocol. This is the protocol a Cisco switch uses to determine (dynamically) that it’s going to trunk with its neighbor, and how (ISL or 802.1q). Now, you can just turn the trunk on if you like, and take all the guesswork out of it. If you leave it up to DTP, and both sides support ISL + 802.1q, ISL will be the winner. If one side supports ISL and 802.1q, but other side only trunks dot1q, then dot1q wins. You can “switchport trunk” to set trunking parameters, if the line is a trunk. You can “show interface trunk” to check and see how the little buggers are doing.
• Doing a “show interface Gi0/1 trunk” would tell you what the DTP mode is for GigabitEthernet 0/1, and how things are working out for that interface (that he’s actually got a status of trunking, and what the protocol is – “n-isl” would mean that ISL is in use, and that it was n=negotiated).
• You can control which of all these nifty VLAN’s you’ve created flow over a trunk line. If you “switchport trunk allowed”, you filter off all VLAN’s not explicitly allowed. For a VLAN to be “allowed and active”, that means that it’s in the VLAN allow list (which is everything, by default), and that the VLAN actually exists on the switch. If the VLAN is “active and not pruned”, it’s the same list as the “allowed and active” list, with pruned VLAN’s removed.
• DTP commands: “switchport mode trunk” – turns trunking on unconditionally, and will still send DTP (and from experience, you have to configure the trunk encapsulation for the port first); “switchport mode trunk + switchport nonegotiate” turns trunking on unconditionally, plus won’t send DTP, which is helpful if the other switch isn’t a Cisco; “switchport mode dynamic desirable” sends DTP, and trunks if the negotiation works out; “switchport mode dynamic auto” listens for DTP messages and replies (but won’t initiate on his own); “switchport mode access” never trunks, and tells the other side that they ain’t never gonna trunk; “switchport mode access + switchport nonegotiate” means that the port will never trunk, and won’t send DTP either.
• You can trunk to a router that has at least a fast-ethernet interface. Routers don’t do DTP, though, so you need to set up the trunking manually. The etherner interface on the router will get broken into subinterfaces, one subinterface per VLAN. The subinterface number does not have to match the VLAN ID (although in my experience that’s not an uncommon way to do it). Instead, there’s an encapsulation statement for each subinterface that tells it what VLAN to tag the frame with. So, really, what happens is that you get a tagged frame that shows up at the router interface. The router has a subinterface with an encapsulation statement that matches the VLAN ID in the tag. There you go, life’s good in the hood. Going the other way, if a packet comes into the router and needs to get routed to that subinterface, the router will tag the frame before it leaves the ethernet interface. Simple, no? You can do native VLAN assignments as well. You can configure one on a subinterface, but if you choose not to, then the router assumes that untagged frames are to be handled by the physical interface. Also note that although there’s no real concept of “allowed VLAN’s” on a tagged router interface, the idea is implied – you HAVE to configure a subinterface for every VLAN that you expect the router to participate in. Otherwise, the tagged frame has nowhere to go as far as the router is concerned.
• And last but not least for today’s chapter…801.q-in-q tunneling! Essentially, you can nest dot1q tags one on top of the other. This is helpful when you want your frames to participate in the same VLAN across service provider space, but the service provider is already using their own VLAN tags. That’s okay with q-in-q. The SP just adds their tag to yours, forwards, and strips it off when it gets to you on the other side of their cloud. CDP and VTP work fine in a q-in-q tunnel.
• The Foundation Summary that isn’t a review adds the following that wasn’t already mentioned: “show mac-address-table”, which shows you details about the layer 2 bridging table.