VLAN confusion
-
The easy way to visualize VLANs is creating completely separate network stacks, but cheaper. VLANs are all about "I wanted separate switches for this, but that was expensive and I can live with the VLAN limitations." So VLANs exist for security and management reasons, but not for performance ones.
So, if you had separate switch stacks, you need a router to talk between them. This creates a bottleneck, but it is your security control point. That's the core functionality of the VLANs: to keep everything completely separate. If you want VLANs to openly talk to each other, then you don't want VLANs at all. VLANs create bottlenecks in exchange for offering LAN based security mechanisms.
-
@dave247 said in VLAN confusion:
Like in a case where I have a VoIP set up, with phones on one VLAN and computers on another. The computers and VoIP systems should normally never need to communicate with each other (I assume) unless there is like some VoIP related application installed on a user's workstation. In that case, I assume that at some point, data is crossing over between the two networks, through the two VLAN's.
That would make VLANing crazy in that instance. If you want the networks to be able to talk, what's the purpose of the VLAN? Phones, specifically, are a really bad place to normally have VLANs.
-
@dave247 said in VLAN confusion:
Also, my main reason for asking this: I am trying to set up a LAB network that will reside on it's own VLAN, completely separate from my company's production systems. But if it's 100% segregated, then I'm not going to be able to access it from my work pc, so I'll have to set up a separate computer that is connected to the lab VLAN. That is, unless I implement some kind of ACL..
Right, just like a LAN somewhere remote on the Internet. You'll need a pinhole for management and/or a PC that sits on that network and not on the company one.
-
@scottalanmiller said in VLAN confusion:
@dave247 said in VLAN confusion:
Like in a case where I have a VoIP set up, with phones on one VLAN and computers on another. The computers and VoIP systems should normally never need to communicate with each other (I assume) unless there is like some VoIP related application installed on a user's workstation. In that case, I assume that at some point, data is crossing over between the two networks, through the two VLAN's.
That would make VLANing crazy in that instance. If you want the networks to be able to talk, what's the purpose of the VLAN? Phones, specifically, are a really bad place to normally have VLANs.
The idea of VLANing phones comes from a misunderstanding of tech at worst and old days of hubs at best. As long as a switch port isn't at 100% utilization, the QoS rules don't apply - the switch will just keeping everything moving. If you have 100% utilization, you probably have other issues you need to resolve before you worry about QoS for phone calls, but phones would definitely feel this pinch faster than other things.
-
@dashrender said in VLAN confusion:
@scottalanmiller said in VLAN confusion:
@dave247 said in VLAN confusion:
Like in a case where I have a VoIP set up, with phones on one VLAN and computers on another. The computers and VoIP systems should normally never need to communicate with each other (I assume) unless there is like some VoIP related application installed on a user's workstation. In that case, I assume that at some point, data is crossing over between the two networks, through the two VLAN's.
That would make VLANing crazy in that instance. If you want the networks to be able to talk, what's the purpose of the VLAN? Phones, specifically, are a really bad place to normally have VLANs.
The idea of VLANing phones comes from a misunderstanding of tech at worst and old days of hubs at best. As long as a switch port isn't at 100% utilization, the QoS rules don't apply - the switch will just keeping everything moving. If you have 100% utilization, you probably have other issues you need to resolve before you worry about QoS for phone calls, but phones would definitely feel this pinch faster than other things.
Which is a weird thought process, given that hubs didn't have QoS capabilities. So QoS only existed in the world where VLANing for QoS didn't make sense.
-
@dashrender said in VLAN confusion:
VLANs in most cases aren't needed unless you have a security reason to do so, and must share hardware over these networks, i.e. one set of APs but two wifi networks - corporate and guest.
Switches perform their job which can easily allow thousands of devices to be on a single flat IP network without the need to break them down into smaller and smaller segments. So if you don't have a security related reason to keep them separate, then your life will be much simpler if you just have a /23 or /22 network instead of the typical /24 (limited to 256 devices).Onto your current setup:
From the sounds of it, your Sonicwall is doing the routing between your VLANs at this point, assuming cross VLAN traffic is happening.You mentioned that you made a VLAN for wifi - then you talk about a guest and corporate wifi - Does this mean your corporate wifi is on the default VLAN and the guest is exclusively on the new VLAN? What provides DHCP to the guest network? What provides DNS to the guest network?
As for your Lab network, you have choices, you can create a completely separate VLAN that only has access to itself and the internet via the sonicwall, or you can enable ACLs that allow the two networks to talk to each other and the Sonicwall will route information between the two.
Ah, I'm an idiot. My brain sucks at recalling information.
So I set up two VLAN's: one for corporate wifi and one for guest wifi. Then Sonciwall handles the routing and DHCP for each network, plus the firewall functionality. DNS to corp is our DC and I just used google's DNS for the guest wifi. Guest wifi doesn't touch our internal systems at all.
-
@dave247 said in VLAN confusion:
@dashrender said in VLAN confusion:
VLANs in most cases aren't needed unless you have a security reason to do so, and must share hardware over these networks, i.e. one set of APs but two wifi networks - corporate and guest.
Switches perform their job which can easily allow thousands of devices to be on a single flat IP network without the need to break them down into smaller and smaller segments. So if you don't have a security related reason to keep them separate, then your life will be much simpler if you just have a /23 or /22 network instead of the typical /24 (limited to 256 devices).Onto your current setup:
From the sounds of it, your Sonicwall is doing the routing between your VLANs at this point, assuming cross VLAN traffic is happening.You mentioned that you made a VLAN for wifi - then you talk about a guest and corporate wifi - Does this mean your corporate wifi is on the default VLAN and the guest is exclusively on the new VLAN? What provides DHCP to the guest network? What provides DNS to the guest network?
As for your Lab network, you have choices, you can create a completely separate VLAN that only has access to itself and the internet via the sonicwall, or you can enable ACLs that allow the two networks to talk to each other and the Sonicwall will route information between the two.
Ah, I'm an idiot. My brain sucks at recalling information.
So I set up two VLAN's: one for corporate wifi and one for guest wifi. Then Sonciwall handles the routing and DHCP for each network, plus the firewall functionality. DNS to corp is our DC and I just used google's DNS for the guest wifi. Guest wifi doesn't touch our internal systems at all.
Yes, that's a good use of VLANs, total separation where separation is fully intended.
VLANs are often used for DMZs as well.
-
@jaredbusch said in VLAN confusion:
Your router will should be the only point that connects traffic from one VLAN to another.
At a very basic level:
You will want to have rules in your router's firewall that allows new/established/related connections from the company LAN to the Lab LAN. But from the Lab LAN to the company LAN it should only allow established.
This will allow you to connect in and have the Lab thing respond but the Lab thing cannot initiate a connection to the company LAN.
OOOOH yeah.. ok that seems obvious now. I can just allow myself access to that network through my Sonicwall via the firewall rules..
-
@dashrender said in VLAN confusion:
@scottalanmiller said in VLAN confusion:
@dave247 said in VLAN confusion:
Like in a case where I have a VoIP set up, with phones on one VLAN and computers on another. The computers and VoIP systems should normally never need to communicate with each other (I assume) unless there is like some VoIP related application installed on a user's workstation. In that case, I assume that at some point, data is crossing over between the two networks, through the two VLAN's.
That would make VLANing crazy in that instance. If you want the networks to be able to talk, what's the purpose of the VLAN? Phones, specifically, are a really bad place to normally have VLANs.
The idea of VLANing phones comes from a misunderstanding of tech at worst and old days of hubs at best. As long as a switch port isn't at 100% utilization, the QoS rules don't apply - the switch will just keeping everything moving. If you have 100% utilization, you probably have other issues you need to resolve before you worry about QoS for phone calls, but phones would definitely feel this pinch faster than other things.
Well, actually, here's one thing I just thought of. We currently have a /23 network where I work, and our current phone system exists on the same network as our computers and servers. We have a lot of addresses taken up by phones right now, so it would be nice to have the phones on their own separate subnet, and my current understanding is that I would want a separate VLAN to use with that separate subnet. Also, in freeing up IP addresses on our company LAN, I've given myself more IP space for my fail over DHCP server should I ever need it.
-
@coliver said in VLAN confusion:
@dashrender said in VLAN confusion:
As for your Lab network, you have choices, you can create a completely separate VLAN that only has access to itself and the internet via the sonicwall, or you can enable ACLs that allow the two networks to talk to each other and the Sonicwall will route information between the two.
He could setup an ACL that only allows the Lab VLAN to contact the internet, and his workstation. What kind of lab is this going to be though? You could easily do this virtually on a desktop with Hyper-v or KVM.
I have a couple extra servers that I want to set up a Hyper-V lab environment with. That server's in the server room and so I wanted to just have it sitting on it's own VLAN with access to the internet and my workstation only. I could use my local workstation, but what's the fun in that when I have big fat juicy servers I can use?
-
@dave247 said in VLAN confusion:
Well, actually, here's one thing I just thought of. We currently have a /23 network where I work, and our current phone system exists on the same network as our computers and servers. We have a lot of addresses taken up by phones right now, so it would be nice to have the phones on their own separate subnet, ......
No, it would not. You identified the mistake, but made a bad leap in how to fix it. Let's read that again...
- We have a /23 network.
- The /23 is too small for our needs.
- We should....
Logically the answer is "make a network of the right size for our needs." But instead, you jumped to subnetting.
-
@dave247 said in VLAN confusion:
... and my current understanding is that I would want a separate VLAN to use with that separate subnet.
Also incorrect. VLANs basically require subnetting (or overlaps) but you never use a VLAN for subnetting. Subnets are simple and effective, VLANs are complex. You only use a VLAN for management and security purposes, never performance, subnetting or any other purpose.
-
@dave247 said in VLAN confusion:
Also, in freeing up IP addresses on our company LAN, I've given myself more IP space for my fail over DHCP server should I ever need it.
I don't understand this bit.
-
@scottalanmiller said in VLAN confusion:
@dave247 said in VLAN confusion:
Well, actually, here's one thing I just thought of. We currently have a /23 network where I work, and our current phone system exists on the same network as our computers and servers. We have a lot of addresses taken up by phones right now, so it would be nice to have the phones on their own separate subnet, ......
No, it would not. You identified the mistake, but made a bad leap in how to fix it. Let's read that again...
- We have a /23 network.
- The /23 is too small for our needs.
- We should....
Logically the answer is "make a network of the right size for our needs." But instead, you jumped to subnetting.
Yes, I have considered widening our network, but then I would have to make so many changes to devices and I wanted to avoid that. Plus, wouldn't making a /22 subnet be over-kill? This is where I don't have real-world knowledge and experience yet. Is it ok to have a company LAN with a huge address range? What if that range hypothetically got filled up? Would that be too much traffic? 1020 computers, servers, printers, and other devices all on the same subnet not a possible congestion issue?
-
@dave247 said in VLAN confusion:
Yes, I have considered widening our network, but then I would have to make so many changes to devices and I wanted to avoid that.
Actually GROWING a network is trivially easy, and DHCP does it automatically for all DHCP managed devices. There's really no good reason not to grow. There is nothing hard about it and it is the real fix, rather than a bandaid.
-
@dave247 said in VLAN confusion:
Plus, wouldn't making a /22 subnet be over-kill?
How could it be overkill when /23 has been identified as inadequate for the needs?
VLAN is the overkill - lots of complexity without benefit. /23 is the proper solution, VLAN is the overkill without all of the benefits of the proper way.
-
@dave247 said in VLAN confusion:
Is it ok to have a company LAN with a huge address range?
Not just okay, it's the enterprise standard. /22 is not huge, /22 is "normal" for large networks. The entire concept of the /24 network being some kind of standard is a mixture of ancient 30 year old class based network identification and SMBs repeating misunderstood myths since that time.
The use of /24 was practical in the pre-switch era. But that specific factor went away around 2000. And class based networking was most of a decade prior to that.
It's not that /22 is huge, it's that /24 is absurdly small.
-
@dave247 said in VLAN confusion:
What if that range hypothetically got filled up? Would that be too much traffic?
Networks (subnets in the 1990s terminology) aren't affected by traffic. That's not a thing. If you had "too much traffic" you'd be impacted with VLANs before you were impacted without them because VLANs add extra overhead and bottlenecks. You never segment switched networks due to traffic load, that was a bus-based networking problem when all traffic traveled on a single bus for the entire network. If the bus filled up, the network would slow down.
The thing you are worried about here is saturating your switch backplane, if you do that, VLANs will hurt, not help. And you need bigger, faster switches. It's not related to your address schema.
-
@dave247 said in VLAN confusion:
1020 computers, servers, printers, and other devices all on the same subnet not a possible congestion issue?
No. Picture your network. What is congestion? Other than the places where VLANs need to talk to each other, there is no congestion point. Congestion is a 1990s term from hubs, it doesn't exist (outside of the switch backplans or the router connection points between VLANs) in the modern world of the last two decades. Switches make each device talk directly to any other device. There is no spot for congestion to exist until you add VLANs, and then only where the VLANs talk to each other.
-
@dave247 said in VLAN confusion:
1020 computers, servers, printers, and other devices all on the same subnet not a possible congestion issue?
Isn't this specifically what switches were designed to fix? @scottalanmiller beat me too it.
