Not that scary or that hard: Two decades of VLANS Next year will see the 20th anniversary of IEEE 802.1Q, the standard that defines the tagged VLAN for Ethernet networks. Despite it being two decades since modern VLANs started being used in anger a significant number of systems administrators remain afraid of them. Unfortunately, the time is upon us where VLANs are becoming a …
Thanks for the summary - will re-read at leisure.
I fin it surprising how many network admins still can't get their heads around VLANs - even some of our "partner" organisations clamp up in fear when they come on our site and hear we use VLANs for segregation on the structure.
They really can be fantastic tools to manage data flow and traffic volumes, and managing which VLANs can access which trunk can be a useful way of ensuring that traffic stays where it's wanted, freeing backbone bandwidth in the process.
One "gotcha" that I've fallen foul of (well two if you count not checking native VLANs when routing between networks - wish I'd read that YESTERDAY!) is that there are differences in implementation and terminology between CISCO implementation and almost everyone else (I cut my teeth on Nortel - dead easy by comparison).
".....I fin it surprising how many network admins still can't get their heads around VLANs....." The admins you have to watch out for are the ones that thinking converting a relatively simple network into a mess of VLANs will somehow protect their jobs....
Did the same, with managed TP-link switches attached to powerline. I have particular fondness for 5-port ones, which are perfect in the role of serving access ports from the powerline adapter. The VLAN-tagged trunk, as you can guess, is the powerline. It is amazing what one can do with small budget and a bit (just enough to be dangerous :-D ) of technical knowledge.
Q-in-q is implemented in proprietary solutions as well that aren't full 802.1ad implementations, but are implementing nesting. This is less common today, but was quite common before the full ratification of 802.1ad.
Aren't standards processes awesome?
I find it unbelievable that people setting up switches don't know what a VLAN is, or don't use them. I've dealt with a number of IT managers and IT contractors who literally have no idea what a VLAN even is.
I've heard all sorts of rubbish reasoning, but never a reason to NOT deploy VLAN's on almost every network by default, the second you take it over.
And if you're worried about adding them to a "legacy" network, just do it. Put anything new on the "new" VLAN's, and access to them, and leave everything on the "default / untagged" VLAN until you can start moving it over.
With server VM's (also a no-brainer that should be your FIRST job if you're taking over a non-virtualised network), it's literally just adding another interface on the necessary VLANs and off you go.
You should be isolated as much as possible.
- Make the default VLAN as boring and empty as possible.
- Separate off wireless, guest wireless, access control, CCTV, telephony (probably job #1!), printers, inter-server traffic, etc. into their own VLAN. Put the necessary VLAN interfaces on the VM's that need it (e.g. telephony integration servers).
Then you can separate and monitor traffic (e.g. CCTV VLAN using much more traffic than telephony VLAN, etc. rather than have to do protocol analysis to find that out), remove any opportunity for browsing and bypassing stuff, and apply completely separate settings to entire VLANs (e.g. QoS on the entire telephony VLAN, rather than on individual endpoints, or DSCP tagging, or port-detection or whatever).
Personally, I think even printers should be on their own VLAN (hint; They don't even need VLAN support for you to do this! Just keep your wiring sensible so that they don't piggyback/share with other devices). That way nobody can "browse" for printers to exploit / prank, and have to go through - say - a Papercut server that's the only "computer" on the printer VLAN, and has a public web interface on the client VLAN. You're also separating out thee broadcast traffic to only those devices that actually need to be listening in on it (not everything does multicast properly) - no more dozens of printers constantly advertising their wares to every port on your network.
And though it might allow you to run two identical IP ranges over two different VLANs on the same cable, I think that's stupid. Just renumber. Internal ranges are plentiful. In fact, I tend to number ranges to mirror the VLAN number - e.g. 192.168.10.x - 192.168.19.x to be on VLAN 1, 192.168.20.x - 192.168.29.x to be on VLAN 2, etc.). Because then you can spot your mistakes so much more easily and someone "just browsing" has much more work to do.
VLANs are a no-brainer. I work for schools and for years, stupid educational companies ingrained the concept of separating wiring for "admin" and "curriculum" networks. When all the kit could have just supported VLANs (and proper damn permissioning / authentication would solve the problem anyway). I still walk into schools wired that way, where a bursar cannot log in in a meeting room, etc. because he's "on a different network" that's physically separated so even domain trusts aren't possible.
VLAN. VM. First two jobs to solve in every workplace that doesn't already have them. Anything else is just madness.
> VLAN. VM. First two jobs to solve...
I get where you are coming from, but from my experience, not sure that's entirely right. On every infrastructure I've inherited I've found that I could not trust the existing backup regime, and that shared storage has not been properly sorted/segregated/versioned.
If you would add Consolidated Storage and Backup to the list, and make it a four way tie, I'll buy in!
I find, if taking over a particularly bad place, that the backups are rarely backing up the CONFIGURATION, i.e. the server, server state, application configuration, etc, properly. Or if they are, it's been cherry-picked to the bare minimum and then never updated as new things are added.
One of my prime reasons for converting to VM is that you can then backup the entire VM image + snapshots beforehand, and as you make changes, and ensure that you have a way to get back to where you started and a FULL backup (and hence even keep the original server and/or the original server disk image to do a full revert if there's a problem, even back to the original hardware).
Part of that, yes, I agree, would be the backup of storage too.
I work for a small IT Support consultancy dealing mainly with SMB's and Schools. We once visited a school to look at some project work. After performing an extensive survey of the network and systems and finding it all a bit of an unholy mess, my colleague jokingly asked the onsite Tech "Where are your VLANs?". He replied that they were in the server cupboard...
I work for a small IT consultancy mainly working with SMB's and Schools. We were invited into a school one time to look into tendering for a site-wide-wireless project. After performing an in depth survey of the network and determining that it was an unholy mess, my colleague asked the on-site Tech in only semi-mock exasperation "Where are all your VLANs?" to which the Tech replied, "Well obviously they're in the server cupboard with the rest of the IT gear".
Your switch has only 1 forwarding table so there will be problems if you have overlapping ip space on same physical infrastructure.
Maybe you won't notice it if it's low traffic.
My switches come with a feature called layer 3 virtual switching (I first used this feature in 2005). You can define virtual switches each of which has a dedicated layer 2 and layer 3 forwarding tables, and vlans (a vlan can belong to only one virtual switch at a time). With this you can safely have overlapping ip networks on the same physical switch. While a Vlan can only belong to one VS at a time you can have say vlan1 on VS1 and vlan2 in VS2 different names and tags but the same ip space. While usually less important you can also have overlapping MAC addresses, that say have two different devices with the same MAC, connected to two different virtual switches and not cause any issue.
The only way to get from one VS to another is a router. Either external to the switch or internal. It's also possibly the only time when it is fine to connect a cable directly between two different ports on the same physical switch (as long as they are in different virtual switches), and not have any fears of causing a loop.
My main datacenter switches use 4 virtual switches on them.
External VS for bridging firewalls with2 vlans
External VS with 4 vlans
Internal ops VS with 20 vlans
Internal corp it VS with 3 vlans
Firewalls bridge bridging VS and external VS, load balancers bridge between external VS and internal ops VS, and firewalls bridge between external VS and internal corp VS.
Also configuring thousands of vlans on a switch I can't imagine that happening on more than a tiny number of orgs out there. Most organizations are much more likely to have many layer 3 domains (each with some subset of vlans behind them), and route between the layer 3 domains. Obviously since these are layer 3 then you can have overlapping vlan tag ids etc between domains.
Oh and none of my networks have EVER used STP or any variant. I use ESRP for combined layer 2 loop protection and layer 3 fault tolerance, far simpler and better in my opinion than STP, and something like VRRP and HSRP for my networks anyway.
about the difference between layer 2 and layer 3 switches, and some hints about inter VLAN routing. Most environment won't work with fully separated VLANs, nor install separate routers just to move some data between VLANs.
And some of my HP switches makes filtering traffic between VLANs so difficult it could be an explanation why someone is afraid of VLANs.
Plus the vendors like Cisco that makes you pay to add more VLANs to your devices.
"Plus the vendors like Cisco that makes you pay to add more VLANs to your devices."
That's not really the case though.
The Cisco devices I deal with allow enough VLANs to perform the job role that the device is designed for.
Most switches (where VLANs are designed to be) are restrained by the memory/IDB allocation, and not by how much money you pay.
Routers are restricted VLAN wise, but this isn't for monetary reasons. Even my basic 887VA at home will support 8 VLANs, and this is more than sufficient for a SOHO router.
If you mean ASAs, then yes they are restricted based on license. From memory it can be as low as 3 VLANs. But then you have to ask yourself why would anyone use a heap of VLANs on a firewall.
We finally got some vlan switches in the place I was at in 2006ish. Before that we had two routers running OpenBSD with two 4 port ethernet cards each. The pile of switches and cables that were disgorged during the upgrade was significant.
It was so nice having one single cable going into each of the routers. The rats nest became downright manageable.
Unfortunately there are some things that vlans can't fix. The morbidly obese owner, who I will call Captain Fantastic, let his chain smoking, alcoholism and reality-tv-show-worthy gluttony gradually morph into extreme hypertension[1], congestive heart failure and narcolepsy[2]. The aforementioned caused Captain Fantastic's brain to mostly turn off, which didn't mix well with his love for tax fraud and fraud[3] in general.
[1] Captain Fantastic said it was "type 2" hypertension. I looked it up and the only reason it was "type 2" is because they stop counting at 2. I can't remember the exact numbers, but his blood pressure was something along the lines of 290/220. His legs lost all definition, no knees, no ankles, just two giant sausages.
[2] He'd nod off mid-conversation. I later found out that he could only sleep sitting up as the fat would completely prevent him from breathing when laying down. The fat gradually got to the point where it prevented him from breathing properly even when sitting. Since he'd never really sleep as sleeping and dying were pretty much the same thing he developed narcolepsy. Luckily the narcolepsy didn't prevent him from driving as he had preconditioned himself by frequently driving with obscene amounts of alcohol in his blood.
One night his wife found him, sitting and completely unresponsive. This was the second time they ambulanced him into emergency (are medical forklifts a thing?). I was told that the next day he was responsive and the heart surgeon paid him a visit (again). The surgeon told everyone to leave the room, closed the door and proceeded to scream very un-surgeon-like things such as "stupid fucking asshole" and "shithead" at Captain Fantastic.
[3] At some about two years before the business mushroom clouded Captain Fantastic decided he was a race car driver, bought a brand new ford mustang and spent the next one and one half years pouring money into the car. This is at a time when we could have heated the building with all of the bills containing phrases like "final notice", "legal action will be taken" and "some guys with crowbars are coming". He would always wear his Mustang Racing leather jacket and cap that must have required a small bovine genocide to construct. Then came the bills addressed to "Captain Fantastic Racing Company". I guess you can just start a blatantly bullshit company, request credit from local businesses and you'll actually get it.
Eventually came Captain Fantastic's plans to transfer ownership of his empire of shit to someone and then declare bankruptcy. The trouble was that no one would touch that steaming pile with an 80' barge pole. That was about when I bailed out.
Years later a mutual acquaintance acquired Captain Fantastic's hosting business. Captain Fantastic had managed to keep a hold of it by selling it to his wife before he declared bankruptcy and the government came around to perform a prostate examination with a shovel. The incredibly unreliable hosting company he had moved to after the last completely unreliable company went mammaries skyward had evaporated overnight. Captain Fantastic had no backups, but he did have ownership of all of his customer's domains.
Over the years I'd managed to wrestle two domains from Captain Fantastic after some of this customers had somehow managed to find me and threw themselves at my feet as they screamed, cried and pointed at their rag wearing, emaciated children. Getting the domains back took months and was about as much fun as trying to steal weapons from a police station, after phoning up said police station and telling them you're coming to steal their weapons.
And that's why VLANs are great!
Don't forget special-case trunking, with voice vlans/dot1p/vlan 0.
Working for a telephony provider we see all sorts of weird and wonderful networks. There's still plenty of businesses running VOIP on their data network. Or because they don't have access to CDP/LLDP commands through the GUI (or they don't take the time to understand it), they would rather hardcode a vlan on 100 phones, or use VLAN discovery via DHCP (urgh).
I would say about 90% of companies still use VLAN 1 throughout the network for their main data vlan, despite the security (and other) consequences.
VLANs are also nice when dealing with IPMI devices that don't have their own physical port. You can separate out the management traffic from the regular traffic. It still won't be as secure as physical separation, but it does mean other machines on access ports won't be able to snoop it.
One issue I ran into a lot is most PXE boot ROMs don't understand VLANs, so if you're trying to bring up a server on a trunk port you can't network boot it. I usually dealt with this by switching the server to an access port, but it was awkward because I didn't control the switches and the central IT department had a policy of not turning on unused switch ports.
Many Linux distros still don't have a convenient way to set a VLAN tag during installation, too, which can make network installs awkward.
Yes, you can assign static IP addresses to DHCP clients and go from there. Assuming that the clients actually take the IP address and correctly use it, it works quite well. While you are there, have devices in different subnets.
Sounds much easier than VLANs, but what do I know. Doing this stuff at level 2 of the network stack seems a bit backward to me.
I could be wrong though, and it wouldn't be the first time. Don't flog me too hard.....
".....Assuming that the clients actually take the IP address and correctly use it, it works quite well...." Ah, yes, but one of the great selling myths the VLAN peddlers push is that VLANs are "more flexible" and you can "reconfigure on the fly". The reality is you usually set up your VLANs and then don't change anything for years.
Nice write-up. Coming from the "it works, don't muck with it" school of networking, I've shied away from playing with VLANs. They sure look cool, but I don't have a testbed network I can play with. Nice to get a real world perspective. Filing away for the day I get to do some network improvements.
It's 2am, why is my phone buzzing? Server down alert? Let me login and check it...
10 mins later. Oh, it's because a VM has DRS migrated to another host. A host which doesn't have that specific VLAN configured on the trunk port from the switch. Cheers network team.
If I had a Euro for every time that has happened...
Wow, many of these comments are downright crazy.
I decided to jump back into IT back in 98, where I should have stayed focused on and gone into after highschool/college in the first place.
Even back then we were ripping out Bay Networks and Cat5000s using CatOS, and aside from the the BN's being unmanaged, we were using VLAN's, STP etc.
Now even 2 decades later and there are technical people responsible for networks who are mystified about IOS Layer 2 Vlans?
If I had to interview someone and they were more familiar with routing than switching, they'd be a no go probably for even an entry level position.
Switching may seem as relevent as Y2k nowadays, however its far faster than routing, and all of your User Access and Distribution networks absolutely rely on it.
Vlans minimize your broadcast domain, provide security segmentation, and make our jobs easier.... What can't Vlans do!
I'm primarily on Cisco kit, and the first thing I used to do when I was implementing or a config monkey was changing the the default native Vlan from 1 to something else, disable Vlan 1 and setting VTP Mode to Transparent.
You only need to work through a fire drill once where some idjit plugs a new switch onto the corporate network which happens to have VTP Mode set to Server, which then proceeds to upload its empty vlan db to all of your switches set to VP Mode Client.
Or because VLAN 1 is up/up he actually connects and starts populating his dept. lab with a DHCP server, router, etc and the Help Desk alerts your Dir to a network outage/incident occurring.
Very shocked to hear about SPB, totally missed that the past years. Checking on it, and now I know why, as it appears Cisco spurned it for TRILL which has died.
I know VSS works without STP, and C3850's and above allow both uplinks to be active with LACP, IIRC.
Absolutely right, being a professional of networking since 1990, it really shocks me to discover that such basic concepts as VLANs are not mastered by everyone who dedicates some part of his time to work with networks.
Now in an enterprise network you normally can go along with a few vlans, the challenge is for massive datacenters (those that the people normally call "the cloud") that have to deal with lots of vlans, and lots of uplinks simultaneously active. That's the kind of problems that VXLAN or TRILL were meant to solve. VXLAN is more popular and has more industry backup, but if there is something less understood in networking this is how IP multicast work, and this is really scary.
If I had to interview someone and they were more familiar with routing than switching, they'd be a no go probably for even an entry level position.
Switching may seem as relevent as Y2k nowadays, however its far faster than routing, and all of your User Access and Distribution networks absolutely rely on it.
In larger networks routing can be preferable to trunking for faster convergence times as opposed to STP/RSTP and to avoid having to have some VLANs on the switches where they would just pass through.
Isolation in VLANs has been an issue for 2 decades. Most of the time it works great but when it fails, it tends to fail open or in very odd ways.
The trick twenty years ago was simply flood the switch with arp packets that would overload the mac table in which case every packet went to every physical port turning it into a hub. That still works in an amzaing amount of current hardware. Long ago you might need to generate a bit over thousand packets while 64k is more typical today, there are machines that get confused with just over 2 million packets which takes all of two seconds to send out.
There are techniques now that make use the mostly unused auto-configure features on different switches that allow it to auto-configure holes in the security.
VLANs are great for "keep the VoIP traffic off the video camera network", You just can't count on it for "keep the R&D secrets isolated from the credit card processing network"
Besides VLANs being one layer only of any security implementations, good switches have port security features to block MAC flooding and other attacks.
If you need to protect ""the R&D secrets" and "the credit card processing network" I hope you don't use cheap switches with limited functionalities, and don't rely on a single layer of protection...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
