At what point does network segmentation/VLANs make sense?

--chris--

I have a client that has ~80 computers, no projected growth in the next 3 years. The PC's are all on one class C subnet run by unmanaged switches, no segmentation.

Right now, the internet is three T1's bonded together. The internal network is not the bottle neck, but they are working with an ISP to get possibly get fiber shortly and I have a concern that the network may become a bottleneck if they put more emphasis on utilizing that fiber line. Their current phone system runs on a dedicated single T1 and would probably stay that way after the Fiber move. They do not do any Skype/video right now, but I imagine they will want to once the fiber is in.

So thats the scenario, at what point would breaking this subnet up start to make sense? If I left anything pertinent out, let me know...I just enough to get this thought in my head, but not enough to design an expansion.

Hondabuff

If you are big enough to have a domain controller then you should start breaking up the network into separate vlans. Servers on one vlan and hosts on another. Cisco quotes that 500 nodes per VLAN is the max that you should go due to broadcast traffic. Good design would be 10.2.0.1/23, then 10.2.2.0, 10.2.4.0. Easy to manage that way for growth and management.

OfWolfAndMan

^Agreed

--chris--

Hondabuff wrote: »

If you are big enough to have a domain controller then you should start breaking up the network into separate vlans. Servers on one vlan and hosts on another. Cisco quotes that 500 nodes per VLAN is the max that you should go due to broadcast traffic. Good design would be 10.2.0.1/23, then 10.2.2.0, 10.2.4.0. Easy to manage that way for growth and management.

Servers on seperate VLAN, is that a best practice or standard that should always be followed?

fredrikjj

My main concern there would be that they are using unmanaged switches without security features like dhcp snooping, etc, not throughput per se. Tracking down issues like that would be challenging to say the least if the switches are dumb.

--chris--

fredrikjj wrote: »

My main concern there would be that they are using unmanaged switches without security features like dhcp snooping, etc, not throughput per se. Tracking down issues like that would be challenging to say the least if the switches are dumb.

Good point that I did not think of. I just read up on that feature...neat stuff.

I sincerely doubt they would ever want to put money into improving their network when its "working" as is, this is more or less a question thats been bugging me. They have corporate mandates, government regulations and audits that determine where money is spent in the IT realm. If the driving force doesn't come from one of those three it wont get done.

So getting back to segmentation issue, assuming this company springs for it; servers would go in one VLAN. All hosts in another VLAN? Or is there a scheme that is frequently followed or used for grouping hosts into VLANs?

YFZblu

fredrikjj wrote: »

My main concern there would be that they are using unmanaged switches without security features like dhcp snooping, etc, not throughput per se. Tracking down issues like that would be challenging to say the least if the switches are dumb.

I agree with you - but if this network is actually flat and unmanaged, it's not defensible to begin with. Sounds like this is a case of just needing it to work and not lifting the lid on it after that. IMO, at this point rogue devices are the least of their worries.

Zartanasaurus

Small company with 80 hosts doesn't need much. I'd split them into 2 VLANs (workstations/servers) and be done with it. Are they coming to you and asking for this? If not, they may just say no since "it works now" and you're asking them to spend money.

it_consultant

--chris-- wrote: »

I have a client that has ~80 computers, no projected growth in the next 3 years. The PC's are all on one class C subnet run by unmanaged switches, no segmentation.

Right now, the internet is three T1's bonded together. The internal network is not the bottle neck, but they are working with an ISP to get possibly get fiber shortly and I have a concern that the network may become a bottleneck if they put more emphasis on utilizing that fiber line. Their current phone system runs on a dedicated single T1 and would probably stay that way after the Fiber move. They do not do any Skype/video right now, but I imagine they will want to once the fiber is in.

So thats the scenario, at what point would breaking this subnet up start to make sense? If I left anything pertinent out, let me know...I just enough to get this thought in my head, but not enough to design an expansion.

My recommendation is to leave it be, but to answer the question, there are a few scenarios where VLANs and segregation become a thing.

1 - Some of your PCs need to be PCI compliant and others don't.
2 - You plan on having more than 500 computers on the subnet at the same time
3 - You need to enforce QOS
4 - Part of your network is in a physically different location
5 - You want your network to take different paths

--chris--

Zartanasaurus wrote: »

Small company with 80 hosts doesn't need much. I'd split them into 2 VLANs (workstations/servers) and be done with it. Are they coming to you and asking for this? If not, they may just say no since "it works now" and you're asking them to spend money.

No, this is all just stuff in my head...they have not requested any of it. I wont be approaching them either...its just a question that I wanted to get an answer to and google failed me.

--chris--

it_consultant wrote: »

My recommendation is to leave it be, but to answer the question, there are a few scenarios where VLANs and segregation become a thing.

1 - Some of your PCs need to be PCI compliant and others don't.
2 - You plan on having more than 500 computers on the subnet at the same time
3 - You need to enforce QOS
4 - Part of your network is in a physically different location
5 - You want your network to take different paths

Thanks for the list, I will be referencing this.

Is this topic similar to what the CCDA/P topics cover?

it_consultant

I have no idea if it is on CCDA/P. It has just been my experience managing networks that those are generally the reasons why one would subnet. I matured in an era which emphasized flattening networks as opposed to structuring them. Hell, I just read that the latest release of the Brocade Fastiron software supports VXLAN which can stitch layer 2 networks on top of layer three networks. This is common in service provider switching but not common in regular bread and butter ethernet switches. The question you should always answer is "why am I doing this?". If the answer is because a certification test showed you how to do it, then it isn't really valid.

Take one example, PCI compliance, a PC must be PCI compliant if it itself handles credit card information, or if it has direct and uncontrolled access to a computer that handles credit card. In a flat network that can easily spread to your entire domain if you haven't segmented. Then you segment based on security zones and put in compensating controls at your segmenting points.

Phones are another good example of when people VLAN when it isn't really necessary. A regular phone call will take a tiny fraction of a 100MB link, what is the point of VLAN'ing that traffic off? For QOS maybe, but that only tells the switch which traffic to process first and which to police and possibly drop if the link gets saturated. Most LAN ports will never saturate. Now, if my phone switch is across a slower WAN link (say a point to point T1) then it is totally conceivable that the link will saturate, at which point you would VLAN your phones at the remote site from the PCs and assign them a higher QOS priority.

In your case people might start using a lot of video, in which case, as you alluded to, the weak point is the internet connection. There are dozens of firewalls that can intelligently prioritize Skype (even Skype vs gtalk or something) and or load balance between more than one internet link.

--chris--

it_consultant wrote: »

I have no idea if it is on CCDA/P. It has just been my experience managing networks that those are generally the reasons why one would subnet. I matured in an era which emphasized flattening networks as opposed to structuring them. Hell, I just read that the latest release of the Brocade Fastiron software supports VXLAN which can stitch layer 2 networks on top of layer three networks. This is common in service provider switching but not common in regular bread and butter ethernet switches. The question you should always answer is "why am I doing this?". If the answer is because a certification test showed you how to do it, then it isn't really valid.

Take one example, PCI compliance, a PC must be PCI compliant if it itself handles credit card information, or if it has direct and uncontrolled access to a computer that handles credit card. In a flat network that can easily spread to your entire domain if you haven't segmented. Then you segment based on security zones and put in compensating controls at your segmenting points.

Phones are another good example of when people VLAN when it isn't really necessary. A regular phone call will take a tiny fraction of a 100MB link, what is the point of VLAN'ing that traffic off? For QOS maybe, but that only tells the switch which traffic to process first and which to police and possibly drop if the link gets saturated. Most LAN ports will never saturate. Now, if my phone switch is across a slower WAN link (say a point to point T1) then it is totally conceivable that the link will saturate, at which point you would VLAN your phones at the remote site from the PCs and assign them a higher QOS priority.

In your case people might start using a lot of video, in which case, as you alluded to, the weak point is the internet connection. There are dozens of firewalls that can intelligently prioritize Skype (even Skype vs gtalk or something) and or load balance between more than one internet link.

Thanks for the observations, i appreciate the insight. I think it should be mentioned again though that this is all an exercise in applying some concepts I learned, I don't plan on running to the customer with this.

Wikipedia's entry on VXLAN is pretty short, why would someone (other than a ISP) desire that setup?

DevilWAH

I think there are a number of reasons to vlan there are the management ones such as it-consultant has mentioned. But also the performance and while not so important on a network of 80 users as the network grows so do that.

One is the single broadcast domain. when a device is in the same ip/vlan segment to the server/client it is trying to connect to it carries out an arp (assuming ipv4) which hits ever NIC on the segment, now on a network of 200-300 clients talking to domain servers and services in a single vlan and you can have back ground "noise" of 50+ ARP packets each second hitting your devices. and while its not a huge impact on performance it does slow down the network. Even worse should a NIC or PC go heywire and start flooding the network every device gets hit, this means if client A starts flooding at 15,000 pps the communication between server B and Client D will be affected, as will the connections between server B and its back end data base server.
So putting servers and clients on a separate vlan can mitigate some of these issues. The general rule is that if you split your network in to groups of machines that talk to each other. ie servers and clients and separate them on to different subnets then you cut down broadcast massively. however sub dividing clients in to separate subnets is only really needed if you need to manage or apply different security to them.

the otehr security things have been covered by others so I wont go over them again.

But vlans give you three benifits

1. Reduce broadcast and in large networks improve throughput and performance by cutting background and overheads.
2. Provide a choke point to apply security between devices.
3. provide a point to monitor the network.

for 80 devices assuming your equipment if reasonable up to date point one is not going to be something to consider you much (unless you get a device flooding the network ) .And unless you are going to introduce monitoring or security on to the network then points 2 and 3 are also not worth the effort.

Ask your self, do I have performance issues? Do I want better visibility of the traffic? Do I need to secure the traffic? If you can answer yes to any of them then you need to consider vlans and segmenting it. if the are all NO then don't bother. If you are not sure, then you need to research it as at what point they become necessary is specific to each individual network.

--chris--

DevilWAH wrote: »

I think there are a number of reasons to vlan there are the management ones such as it-consultant has mentioned. But also the performance and while not so important on a network of 80 users as the network grows so do that.

One is the single broadcast domain. when a device is in the same ip/vlan segment to the server/client it is trying to connect to it carries out an arp (assuming ipv4) which hits ever NIC on the segment, now on a network of 200-300 clients talking to domain servers and services in a single vlan and you can have back ground "noise" of 50+ ARP packets each second hitting your devices. and while its not a huge impact on performance it does slow down the network. Even worse should a NIC or PC go heywire and start flooding the network every device gets hit, this means if client A starts flooding at 15,000 pps the communication between server B and Client D will be affected, as will the connections between server B and its back end data base server.
So putting servers and clients on a separate vlan can mitigate some of these issues. The general rule is that if you split your network in to groups of machines that talk to each other. ie servers and clients and separate them on to different subnets then you cut down broadcast massively. however sub dividing clients in to separate subnets is only really needed if you need to manage or apply different security to them.

the otehr security things have been covered by others so I wont go over them again.

But vlans give you three benifits

1. Reduce broadcast and in large networks improve throughput and performance by cutting background and overheads.
2. Provide a choke point to apply security between devices.
3. provide a point to monitor the network.

for 80 devices assuming your equipment if reasonable up to date point one is not going to be something to consider you much (unless you get a device flooding the network ) .And unless you are going to introduce monitoring or security on to the network then points 2 and 3 are also not worth the effort.

Ask your self, do I have performance issues? Do I want better visibility of the traffic? Do I need to secure the traffic? If you can answer yes to any of them then you need to consider vlans and segmenting it. if the are all NO then don't bother. If you are not sure, then you need to research it as at what point they become necessary is specific to each individual network.

Not only is networking pretty new to me, but so is advising/managing a client. My first job was in a large corp. We had duties, we did them and that was that.

With this job we act as the entire IT department, which means people want to be advised and informed about issues they should be considering. With your example, this brings the topic into the scope of "possible" advisement since up time is of extreme importance to them. If one NIC were to crap out (there is at least 80 of them, the odds cant be in their favor) it would cause a real mess for them which would take some time to figure out. But aside from that one issue, I don't see this being something they want to discuss.

Thanks again, I am getting all these scenarios out of my head finally

it_consultant

It is good to have these discussions. One of my frustrations with network engineers and indeed, networking certifications, is that they only really solve half of the issue for a system. For example, it frustrates me that CCNP will teach you how to etherchannel, but based on that you would be completely unqualified to actually etherchannel to a server whether it is VMWARE or Windows or Linux. Network guys are now expected to really be able to do end to end connectivity to include operating systems. I am really not good at my job if I can't jump into really any system and configure the networking. Part of that is understanding when Cisco calls something "etherchannel" and say Hitachi calls it "redundant links" which really means LACP bonding . I find these forums help people (even though this one has been quiet lately) make those bridges.

As for VXLAN, the use in an enterprise would be limited. I can imagine scenario where two large clusters of servers are connected by an aggregation switch where server A in cluster A needs to be able to be on the same broadcast domain as server B in cluster B. Doing a provider VLAN setup or MPLS over ethernet would be way too much overhead for that need, physically moving the server could be impossible - enter the idea of VXLAN. Brocade, Arista, and Cisco have a huge footprint in the datacenter and they offer VXLANs so there must be some sort of demand. That scenario is actually a good reason to do software defined networking.

--chris--

it_consultant wrote: »

It is good to have these discussions. One of my frustrations with network engineers and indeed, networking certifications, is that they only really solve half of the issue for a system. For example, it frustrates me that CCNP will teach you how to etherchannel, but based on that you would be completely unqualified to actually etherchannel to a server whether it is VMWARE or Windows or Linux. Network guys are now expected to really be able to do end to end connectivity to include operating systems. I am really not good at my job if I can't jump into really any system and configure the networking. Part of that is understanding when Cisco calls something "etherchannel" and say Hitachi calls it "redundant links" which really means LACP bonding . I find these forums help people (even though this one has been quiet lately) make those bridges.

As for VXLAN, the use in an enterprise would be limited. I can imagine scenario where two large clusters of servers are connected by an aggregation switch where server A in cluster A needs to be able to be on the same broadcast domain as server B in cluster B. Doing a provider VLAN setup or MPLS over ethernet would be way too much overhead for that need, physically moving the server could be impossible - enter the idea of VXLAN. Brocade, Arista, and Cisco have a huge footprint in the datacenter and they offer VXLANs so there must be some sort of demand. That scenario is actually a good reason to do software defined networking.

From the perspective of the trainee (someone like me) it would appear as though the typical networking job is heavily segmented and all a tech/engineer would need to know is how to router and switch packets/frames from A to B while providing security or redundancy. But like you just mentioned, its more than that.

Bare with me, i just started into WAN technology....

Doesn't frame relay achieve the same end result as VXLAN? I thought broadcast domains could be split among different physical locations with the current set of tools and protocols, why VXLAN?

Etherchannel is now introduced in CCNA btw

powmia

VXLAN...

Scalability is only achieved when you disassociate layer-2 and broadcast (think about that long and hard when comparing to legacy protocols).

VXLAN is actually becoming more and more enticing for enterprises. Every network requires some form of segmentation.. when you have a virtual infrastructure that requires it at the VM level, VXLAN makes a lot of sense once you decide that your segmentation needs to be flexible and scale. The fact that a VXLAN solution such as NSX doesn't actually require you to setup VXLAN gateways on any external devices... having that overlay that doesn't care what vendor made the boxes in your fabric is huge.

DevilWAH

I think as people actually embrace IPv6 a lot of these solutions to solve layer 2 issues are going to become redundant. Particularly the idea of a vlan, we are starting to see the idea when policies that use to be applied at the gateway level are now being applied to the port level.

SDN, BYOD and IPv6 and I think we are over the next 10-15 years going to see a complete change in how networks are managed. The legacy way we have been doing it is just not suitable, and things like VxLAN are just sticking plasters to make it work.

powmia

Sticking plasters is what networking is made of. We have been doing that for the last 30 years and no buzz-word technology is going to change that. How do IPv6, SDN, BYOD??? etc solve multi-tenancy and scale? Yes, even most enterprises need multi-tenancy, whether it is something as small as separating database and UC servers in your virtual environment (because nobody is saving money by running physical hosts these days) or hosting IaaS/PaaS around the globe. VXLAN is a technology that solves that. Will VXLAN be what we're using en mass 10 years from now... highly doubt it, but it doesn't change the fact that the functional requirements will still be there and no fundamental protocol can meet those requirements by itself.

If you think that these neat technologies are there to solve the problem of layer-2 domain limitations, you're wrong. The application folks have finally realized that coding an application to only support clustering at the layer-2 level is lazy and stupid. Even VMware supports layer-3 vMotions now (they do, no matter what they tell you... if you let your account team know that your setup requires layer-3 vMotion, they will document it and support your design from that point on). Anybody that knows what they are doing isn't buying into the TRILL/FabricPath/SPB crap, they are building layer-3 fabrics, because they are the only ones that scale.

These technologies are there to support mobility of hosts... because no matter what you do: 1) Hosts will need a default gateway and you don't want that to turn into a physical location requirement. 2) Segmentation will always be required and BGP is going nowhere. How do you map groups of systems (running in virtual networks in hypervisors to VRFs at large scale without an overlay?

If you're looking for a single protocol that addresses these concerns that plague almost every environment out there... you're looking for a poor design. It cracks me up when people think that the entire TCP/IP paradigm is jacked up, because we have built layer upon layer upon layer. Look at this from a network design 101 perspective. We build networks with modularity to scale our networks, isolate fault domains, ease in troubleshooting, create policy (routing & security) boundaries, etc. Modularity needs to be three dimensional. We are able to troubleshoot the largest networks in the world, because we break them up into bite-size chunks. Something is broken; OSPF is solid, labels are there, peerings are up, oh... our route-targets got hosed by our automation software. Imagine troubleshooting a network that solves those same requirements, but was build with a single wild-ass 'next-gen' protocol.... F* that and good luck staffing your support teams for less than 200k/head from tier I - tier IV.

Rant.. yup, sorry... just had to.

powmia

apologies for the thread-jacking