Does vlan'ing an environment add complexity over simply separating a network physically? Large or small doesn't matter, but for this scenario let's say one office, 2 floors with users, VOIP phones and equipment spread across both floors. Small company with less than 100 users and 200 end devices at least.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Concept question about vlans
- Thread starter drewdown
- Start date
for me it adds simplicity. you can create a vlan per department and put acls in place because you dont want admins accessing IT department stuff. also, when there is a problem with an admin pc, you know you have to troubleshoot vlan X and you wont have to troubleshoot vlan Y because you know thats the phone vlan
my 2 cents
my 2 cents
I agree. You are logically separating networks rather than physically, which is more equipment (routers), more cabling, etc.
/
tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!
/
tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!
VinceWhirlwind
Technical User
I'll play devil's advocate here - configuring VLANs increases the skill level required to manage the network: loads of people who end up managing peoples' networks have not even the first idea about VLANs, so just bear that in mind before instituting them.
Having said that - if they have VoIP on the network, you need to separate that from the Data by way of VLAN anyway, and once you've got even part of your network off VLAN1, then you might as well go the whole hog and use VLANs.
Having said that - if they have VoIP on the network, you need to separate that from the Data by way of VLAN anyway, and once you've got even part of your network off VLAN1, then you might as well go the whole hog and use VLANs.
I would think one would need to know about vlans before getting the concepts of VoIP down...
/
tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!
/
tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!
VinceWhirlwind
Technical User
You would *think* that.....but I was once asked to build a LAN for a VoIP implementer - I asked for their design and got a crazy collage of bits of manual cut'n'pasted.... not good.
So I built a nice simple vanilla LAN out of 3750s - Data on VLAN20, Voice on VLAN200, 1 Layer-3 core, a bunch of Layer-2 edges.
Simple.
The VoIP "implementer" complained - "The network guy is trying to make this really complicated - he's created all these things called "VLANs" and it's making things difficult".
They'd never heard of VLANs.
And bear in mind this completely incapable "VoIP implementer" happens to be Australia's largest telecommunications company. They can't design, can't project manage and can't implement or troubleshoot.
They *are* pretty dynamic when it comes to turning up to meetings and lying through their teeth, though.
The most completely useless shower of @^%#s have ever had the misfortune of having to deal with.
I have since done work for large govt. departments who've said stuff like "That'll go out to tender. But we will never in a pink fit allow <useless shower> to pick up the work".
No idea how they stay in business.
So I built a nice simple vanilla LAN out of 3750s - Data on VLAN20, Voice on VLAN200, 1 Layer-3 core, a bunch of Layer-2 edges.
Simple.
The VoIP "implementer" complained - "The network guy is trying to make this really complicated - he's created all these things called "VLANs" and it's making things difficult".
They'd never heard of VLANs.
And bear in mind this completely incapable "VoIP implementer" happens to be Australia's largest telecommunications company. They can't design, can't project manage and can't implement or troubleshoot.
They *are* pretty dynamic when it comes to turning up to meetings and lying through their teeth, though.
The most completely useless shower of @^%#s have ever had the misfortune of having to deal with.
I have since done work for large govt. departments who've said stuff like "That'll go out to tender. But we will never in a pink fit allow <useless shower> to pick up the work".
No idea how they stay in business.
Wow, I guess it does depend on the people with whom one deals...
I have met some dippy mothers out there, but none as bad as what you describe. Close---in fact, a company not as big, but the same almost, nevertheless...
/
tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!
I have met some dippy mothers out there, but none as bad as what you describe. Close---in fact, a company not as big, but the same almost, nevertheless...
/
tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!
- Thread starter
- #9
Revisiting this topic again.
Would it be safe to say VLANs can add some simplicity and some complexity to an environment if you aren't careful?
How would you separate VLANs? Geographically? What if you have a server room and many servers, many of which need to reside on separate networks? Would you put a separate switch in each rack for each network? Or would you just run a trunk and provision some ports in the appropriate vlan?
Wouldn't this add confusion to a large network? But could work on a smaller network?
Would it be safe to say VLANs can add some simplicity and some complexity to an environment if you aren't careful?
How would you separate VLANs? Geographically? What if you have a server room and many servers, many of which need to reside on separate networks? Would you put a separate switch in each rack for each network? Or would you just run a trunk and provision some ports in the appropriate vlan?
Wouldn't this add confusion to a large network? But could work on a smaller network?
Well, First things first. Vlans are a management tool, that also lay cliam to added security. Are they complex? Yes and no. So many managers have the misconception of "easier managemnt" which it is if you know what your doing.
The idea sounds good. "OMG a virus on one of the sales teams computer! Shut down the Sales vlan before it spreads" Powerful stuff. The manager hearing this from someone JUMPS and is like tonight i implement vlans. Well what happens then is i usually i get called in the next day, and they ask me "why is everything so F**ed Up? Well, lets see the mystery of why DHCP is not working, DNS, or anything at that is best explained like this, telling some one they are brining up multiple different networks in one building. Shocked, they either ask me to bail them out and fix it, or remove it all and put it all back they way it was.
The main concept of vlans was that you are not obliged anymore to separate the company based on geographical location. But on a logical level. (sales, accounting, r&d etc)
And your server room scenario is too vague. if you have server room with 200 servers and every 50 need a network, well you bring up 4 different networks, simple. I cant really answer this ? i dont know what your asking.
But in short, they are a large company tool usually 100 -150 + company. But most if not all vlans deployed at level lower than that are for academic reasons, such as broadcast storms and the like. No real benefit.
-mike
20 yrs old, working towards my CCNP. Looking for a new job
02472
The idea sounds good. "OMG a virus on one of the sales teams computer! Shut down the Sales vlan before it spreads" Powerful stuff. The manager hearing this from someone JUMPS and is like tonight i implement vlans. Well what happens then is i usually i get called in the next day, and they ask me "why is everything so F**ed Up? Well, lets see the mystery of why DHCP is not working, DNS, or anything at that is best explained like this, telling some one they are brining up multiple different networks in one building. Shocked, they either ask me to bail them out and fix it, or remove it all and put it all back they way it was.
The main concept of vlans was that you are not obliged anymore to separate the company based on geographical location. But on a logical level. (sales, accounting, r&d etc)
And your server room scenario is too vague. if you have server room with 200 servers and every 50 need a network, well you bring up 4 different networks, simple. I cant really answer this ? i dont know what your asking.
But in short, they are a large company tool usually 100 -150 + company. But most if not all vlans deployed at level lower than that are for academic reasons, such as broadcast storms and the like. No real benefit.
-mike
20 yrs old, working towards my CCNP. Looking for a new job
02472
- Thread starter
- #12
I want to know some downsides to VLAN's. Or some problems that people have run into concerning them.
I for one have been told that they too add complexity, that if you are doing the 1 layer 3 switch and a handful of layer 2 edge switches with VLANs spread across your network. And you have all vlans existing on every switch then you must know what is what before you can manage them. IE someone can't just walk in and plug in a cable and be up and running because they don't know which port is in which vlan, unless you have some kind of port design, but that can hard to implement. Especially if you have 1 device that needs to be on a separate vlan and 43 on another vlan.
That can be seen as both good and bad depending on who is looking at it? Catch my drift?
I for one have been told that they too add complexity, that if you are doing the 1 layer 3 switch and a handful of layer 2 edge switches with VLANs spread across your network. And you have all vlans existing on every switch then you must know what is what before you can manage them. IE someone can't just walk in and plug in a cable and be up and running because they don't know which port is in which vlan, unless you have some kind of port design, but that can hard to implement. Especially if you have 1 device that needs to be on a separate vlan and 43 on another vlan.
That can be seen as both good and bad depending on who is looking at it? Catch my drift?
The biggest downside of vlans is that anyone who thinks they now what they are can try to implement them, Vlans take planning. You don't pick them up in a 3 day study period, and you most definitely will have routing issues if you add a second layer 3 switch not configured properly. Which will lead to service interruption.
First check out VTP. Thats cisco's vlan management protocol,
and all ports not specially in a designated vlan are in vlan one. (or default vlan). Thus allowing granular control of what resources unauthorized personnel are allowed to access if they plug into a switch and the are not suppose too.
I think you might want to get a CCNA book and read about vlans, The questions you are asking are coming from a lack of a basic understanding of vlans, and you are forming your decision on the basis of others, and without a good understanding you will get contradicting experiences from them.
-mike
20 yrs old, working towards my CCNP. Looking for a new job
02472
First check out VTP. Thats cisco's vlan management protocol,
and all ports not specially in a designated vlan are in vlan one. (or default vlan). Thus allowing granular control of what resources unauthorized personnel are allowed to access if they plug into a switch and the are not suppose too.
I think you might want to get a CCNA book and read about vlans, The questions you are asking are coming from a lack of a basic understanding of vlans, and you are forming your decision on the basis of others, and without a good understanding you will get contradicting experiences from them.
-mike
20 yrs old, working towards my CCNP. Looking for a new job
02472
- Thread starter
- #14
Mahlad29, I think you misunderstood me, I already have my CCNA and I am fully versed in the implementation and management of VLANs. I am just looking for others with real world experience with them and their thoughts on the complexity or lack thereof. And not whatever Cisco tells you it is.
VinceWhirlwind
Technical User
Real-world experience? Let's see.....
Some of the problems I've come across:
As you say, "...all VLANs existing on every switch...". You see this a lot - it's truly horrible. I think it's a Cisco thing, because by default Cisco .1q trunks have ALL VLANs on them and you have to go to the "effort" of pruning them, which nobody seems to bother doing. Other vendor switches make you create your .1q trunk, THEN decide what VLANs you want on it and add them to it or you manually add "untagged" VLANs to a port.
So this comes back to having a decent design to start off with, AND a proper implementation plan. In the real world, people buy switches, power them up and plug stuff into them and everything works so they never bother with a plan, design, or any thought of VLANs.
I'm currently working on a flat LAN with about 1500 devices on it, all in VLAN1.
So my plan is to go to each comms cabinet in the building and one-by-one migrate all the switches in each cabinet to their own new VLAN.
Simple.
Then the people whose network it is get involved - "We want all the printers on 1 VLAN, and then all the Executive on another VLAN, and then everybody who uses the Xena server on their own VLAN....etc...."
Why? Why do you want a horrible mish-mash of bits of VLAN all over the place?
So ultimately the drawback is that people don't know how to use them, which is what makes it complicated.
Some of the problems I've come across:
As you say, "...all VLANs existing on every switch...". You see this a lot - it's truly horrible. I think it's a Cisco thing, because by default Cisco .1q trunks have ALL VLANs on them and you have to go to the "effort" of pruning them, which nobody seems to bother doing. Other vendor switches make you create your .1q trunk, THEN decide what VLANs you want on it and add them to it or you manually add "untagged" VLANs to a port.
So this comes back to having a decent design to start off with, AND a proper implementation plan. In the real world, people buy switches, power them up and plug stuff into them and everything works so they never bother with a plan, design, or any thought of VLANs.
I'm currently working on a flat LAN with about 1500 devices on it, all in VLAN1.
So my plan is to go to each comms cabinet in the building and one-by-one migrate all the switches in each cabinet to their own new VLAN.
Simple.
Then the people whose network it is get involved - "We want all the printers on 1 VLAN, and then all the Executive on another VLAN, and then everybody who uses the Xena server on their own VLAN....etc...."
Why? Why do you want a horrible mish-mash of bits of VLAN all over the place?
So ultimately the drawback is that people don't know how to use them, which is what makes it complicated.
- Thread starter
- #16
Thanks Vince.
I was under the impression when you configure a .1q trunk you have to allow vlans to pass over them, IE specify what is allowed, like so:
swtich(config)# switchport trunk allowed vlan 1,2,3,4,5,6,7,8,9,19
Also, the scenario you described is the problem I am running into now, roughly 10 VLANS existing on every switch in the building, although not everyone of them being used. Maybe 3 at the most depending on where the switch is located. But they are configured on every switch and allowed on every trunk.
In this scenario you could either A) prune the unused VLANS or B) configure a separate VLAN for every switch? How would you handle server racks where you have limited space and limited switches to accommodate multiple networks? IE some racks will have 5 separate networks housed in them. Also how would you hand VOIP and Data on separate floors? Separate VLAN's for both on every floor? Or would you extend 2 VLANs across the building for both DATA and VOIP?
I was under the impression when you configure a .1q trunk you have to allow vlans to pass over them, IE specify what is allowed, like so:
swtich(config)# switchport trunk allowed vlan 1,2,3,4,5,6,7,8,9,19
Also, the scenario you described is the problem I am running into now, roughly 10 VLANS existing on every switch in the building, although not everyone of them being used. Maybe 3 at the most depending on where the switch is located. But they are configured on every switch and allowed on every trunk.
In this scenario you could either A) prune the unused VLANS or B) configure a separate VLAN for every switch? How would you handle server racks where you have limited space and limited switches to accommodate multiple networks? IE some racks will have 5 separate networks housed in them. Also how would you hand VOIP and Data on separate floors? Separate VLAN's for both on every floor? Or would you extend 2 VLANs across the building for both DATA and VOIP?
I will usually create different VLANs for a field office like so;
data(pc/laptops)
voice
servers
network(switches/routers)
printers
apc
for larger facilities that have multi floors, do the same but have a data vlan for each floor. if you use wifi, create a vlan for that, if you have guest users create a vlan for them. The reason for creating a guest vlan is so that you can put in an ACL to allow them to use the printers and get to the internet.. nothing else. I have never believed in setting up different vlans for different departments unless you are doing something like dot1x port security where they will look at the credentials of the person logging in and select what vlan to put them in.
Everyone will have their own way and methodology for setting up vlans and it comes right down to what is best suited for the enviroment you are working on.
The #1 thing you will want to do no matter what... never use VLAN1.
------------------------------------
Dallas, Texas
Telecommunications Tech
CCVP, CCNA, Net+
CCNP in the works
data(pc/laptops)
voice
servers
network(switches/routers)
printers
apc
for larger facilities that have multi floors, do the same but have a data vlan for each floor. if you use wifi, create a vlan for that, if you have guest users create a vlan for them. The reason for creating a guest vlan is so that you can put in an ACL to allow them to use the printers and get to the internet.. nothing else. I have never believed in setting up different vlans for different departments unless you are doing something like dot1x port security where they will look at the credentials of the person logging in and select what vlan to put them in.
Everyone will have their own way and methodology for setting up vlans and it comes right down to what is best suited for the enviroment you are working on.
The #1 thing you will want to do no matter what... never use VLAN1.
------------------------------------
Dallas, Texas
Telecommunications Tech
CCVP, CCNA, Net+
CCNP in the works
You can do a lot with VLANs, including L2 vlans, like mac-address-security, VACLs, MAC ACL, etc. Logically separating the broadcast domain into multiple broadcast domains allows security by separation, as Dallas has pointed out. True, it requires knowledge, but I would rather someone learn the ina and outs of VLANs rather than have someone jump into an unsecured guest wifi access and hop into a management PC, or even have a worker PC have access to a management PC, or even servers---the list goes on and on.
You need switches for users to have access to the network, and with the need for separation, it is smarter to have vlans in those switches rather than have a router for each department. The best way is how Cisco lays it out---Core for backbone high speed switching, distribution for separation and creation of vlans and access rules (acls, etc) and access layer switches for plugging pcs into the network.
/
tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!
You need switches for users to have access to the network, and with the need for separation, it is smarter to have vlans in those switches rather than have a router for each department. The best way is how Cisco lays it out---Core for backbone high speed switching, distribution for separation and creation of vlans and access rules (acls, etc) and access layer switches for plugging pcs into the network.
/
tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!
VinceWhirlwind
Technical User
Drew: "Also how would you hand VOIP and Data on separate floors? Separate VLAN's for both on every floor? Or would you extend 2 VLANs across the building for both DATA and VOIP?"
That depends on how you're scaling it - decide this in the design stage and then implement it as designed.
Generally, I would have my floors separated like this:
Network Management VLAN 10
Data Centre: Server VLAN 50
Floor1: Data VLAN 101, Voice VLAN 501
Floor2: Data VLAN 102, Voice VLAN 502
etc..
With at least one more VLAN for your transit subnet to your WAN connection.
There's rarely any reason for additional VLANs on each floor - except sometimes a Test/Dev VLAN for some users, or maybe a VLAN for a particular group of contractors/project staff who are trusted more than "guests" but not fully.
In this day and age all your users access email, file & print services in the same place and authentication/access security is done at the server end, so access lists on VLANs to separate departments isn't something I've seen any real need for since Windows NT was invented.
And LANs at different security classifications would usually be physically separated on their own switches with a firewall in the Data Centre joining the two "Core" switches. Eg, your "guest", "DMZ", "Production LAN", "Protected" networks should be separated from each other in this way.
That depends on how you're scaling it - decide this in the design stage and then implement it as designed.
Generally, I would have my floors separated like this:
Network Management VLAN 10
Data Centre: Server VLAN 50
Floor1: Data VLAN 101, Voice VLAN 501
Floor2: Data VLAN 102, Voice VLAN 502
etc..
With at least one more VLAN for your transit subnet to your WAN connection.
There's rarely any reason for additional VLANs on each floor - except sometimes a Test/Dev VLAN for some users, or maybe a VLAN for a particular group of contractors/project staff who are trusted more than "guests" but not fully.
In this day and age all your users access email, file & print services in the same place and authentication/access security is done at the server end, so access lists on VLANs to separate departments isn't something I've seen any real need for since Windows NT was invented.
And LANs at different security classifications would usually be physically separated on their own switches with a firewall in the Data Centre joining the two "Core" switches. Eg, your "guest", "DMZ", "Production LAN", "Protected" networks should be separated from each other in this way.
- Status