{"id":629,"date":"2014-10-23T21:42:12","date_gmt":"2014-10-24T02:42:12","guid":{"rendered":"http:\/\/www.smbitjournal.com\/?p=629"},"modified":"2017-02-19T03:39:19","modified_gmt":"2017-02-19T08:39:19","slug":"one-big-flat-network","status":"publish","type":"post","link":"https:\/\/smbitjournal.com\/2014\/10\/one-big-flat-network\/","title":{"rendered":"One Big Flat Network"},"content":{"rendered":"
There is a natural movement of networks to become unnecessarily complicated. \u00a0But there is great value in keeping networks clean and simple. \u00a0Simple networks are easier to manage, more performant and more reliable while being generally less expensive. \u00a0Every network needs a different level of complexity and large networks will certainly need an extensive level of it, but small businesses can often keep networks extremely simple which is part of what makes smaller businesses more agile and less expensive, giving them an edge over their larger counterparts. \u00a0This is an edge that they must leverage because they lack the enterprise advantage of scale.<\/p>\n
There are two ways to look at network complexity. \u00a0The first is the physical network – the actual setup of the switches and routers that make up the network. \u00a0The second is the logical network – how IP address ranges are segmented, where routing barriers exist, etc. \u00a0Both are important to consider when looking at the complexity of your network.<\/p>\n
It should be the goal of any network to be as simple as possible while still meeting all of the goals and requirements of the network. \u00a0<\/em><\/p>\n The first aspect we will address is the physically flat network. \u00a0 Reducing a physical network to be flat can have a truly astounding effect on the performance and reliability of \u00a0that network. \u00a0In a very small network this could mean working from a single switch for all connections. \u00a0Typically this is only available for the very smallest networks as switches rarely are available above forty-eight or possibly fifty-two ports. \u00a0But for many small businesses this is completely possible. \u00a0It may require additional cabling for a building, in order to bring all connections back to a central location, but can often be attained – at least on a site by site basis. \u00a0Many businesses today have multiple locations or staff working from home and this can make the network challenges much greater, although each location can strive for its own simplicity in those cases.<\/p>\n As a network grows the concept of the single switch can be grown as well using the concept of switch stacking. \u00a0Stacked switches share a single switching fabric or backplane. \u00a0When stacked they behave as a single switch but with more ports. \u00a0(Some switches do true backplane sharing and some mimic this with very high speed uplink ports with shared management via that port.) \u00a0A switch stack is managed as a single switch making network management no more difficult, complex or time consuming for a stack than for a single switch. \u00a0It is common for a switch stack to grow to at least three hundred ports if not more. \u00a0This allows for much larger physical site growth before needing to leave the single switch approach.<\/p>\n In some cases, some large module single switch chassis will grow even larger than this allowing for four hundred or more ports in a single switch but in a “blade like” enterprise switching chassis.<\/p>\n By being creative and looking at simple, elegant solutions it is entirely possible to keep even a moderately large network contained to a single switching fabric allowing all network connections to share a single backplane.<\/p>\n The second area that we have to investigate is the logical complexity of the network. \u00a0Even in physically simple networks it is common to find small businesses investing a significant amount of time and energy into implementing unnecessary subnets or VLANs and all of the overhead that comes with those.<\/p>\n Subnetting is rarely necessary in a small or even a smaller medium-sized business. \u00a0Traditionally, going back to the 1990s, it was very common to want to keep subnets to a maximum of 256 devices (or a \/24 subnet) because of packet collision, broadcasts and other practical issues. \u00a0This made a lot of sense in that era when hubs were used instead of switches and broadcasts were common and network bandwidth was lucky if it was 10Mb\/s on a shared bus. \u00a0Today’s broadcast light, collision free, 1Gb\/s dedicated channel networks experience network load in a completely different manner. \u00a0Where 256 devices on a subnet was an extremely large network then, having more than 1,000 devices on a single subnet is a non-issue today.<\/p>\n These changes in how networks behave mean that small and medium businesses almost never need to subnet for reasons of scale and can comfortably use a single subnet for their entire business reducing complexity and easing network management. \u00a0More than a single subnet may be necessary to support specific network segmentation like separating production and guest networks, but scale, the reason traditionally given for subnetting networks, becomes an issue solely of larger businesses.<\/p>\n It is tempting to want to implement VLANs on every small business environment as well. \u00a0Subnetting and VLANs are often related and often confused, but subnets often exist without VLANs, while VLANs do not exist without subnets.<\/p>\n In large environments VLANs are a foregone conclusion and it is simply assumed that they will exist. \u00a0This mentality often filters down to smaller organizations who are often tempted to apply this to businesses which lack the scale that makes VLAN management make sense. \u00a0VLANs should be relatively uncommon in a small business network.<\/p>\n The most common place where I see VLANs used when they are not needed is in Voice over IP or VoIP networks. \u00a0It is a common assumption that VoIP has special needs that require VLAN support. \u00a0This is not true. \u00a0VoIP and the QoS that it sometimes needs are available without VLANs and often will work better without them.<\/p>\n VLANs really only become important when either management is needed at large scale (where scale is larger than a single subnet can provision) and cannot be physically segregated or when specific network-layer security is needed which is relatively rare in the SMB market. \u00a0VLANs are very useful and do have their place. \u00a0VLANs are often used if a dedicated guest network is needed but generally in a small business guest access is provided via a direct guest connection to the Internet rather than a quarantined network for guests.<\/p>\n The most common practical use of a VLAN in an SMB is likely to be a walled garden DMZ designed for quarantined BYOD remote access where BYOD devices connect much like guests but have the ability to access remote access resources like RDP, ICA or PCoIP protocols. \u00a0VLANs would also be popular for building traditional DMZs for externally facing public services such as web and email servers – except that these services are not commonly kept on the local network for hosting in today’s SMBs so this classic use of VLANs in the SMB is rapidly fading.<\/em><\/p>\n Another use case where VLANs are often used inappropriately is for a Storage Area Network or SAN. \u00a0It is best practice that a SAN be a completely independent (air gapped), physically unique network unrelated to the regular switching infrastructure. \u00a0It is generally not advised that a SAN be created using VLANs or subnets but instead be on dedicated switches.<\/em><\/p>\n It is tempting to add complex switching setups, additional subnets and VLANs because we hear about these things from larger environments, they are fun and exciting, and they appear to add job security by making the network more difficult to maintain. \u00a0Complex networks require higher end skills and can seem like a great way to use that networking certificate. \u00a0But in the long run, this is a bad career and IT strategy. \u00a0Network complexity should be added in a lab for learning purposes, not in production networks. \u00a0Production networks should be run as simply, elegantly and cost effectively as possible.<\/p>\n With relatively little effort, a small business network can likely be designed to be both physically and logically very simple. \u00a0The goal, of course, is to come as close as possible to creating single, flat network structure where all devices are physical and logical peers with no unnecessary bottlenecks or protocol escalations. \u00a0This improves performance and reliability, reduces costs and frees IT resources to focus on more important tasks.<\/p>\n Originally posted on the StorageCraft Blog<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" There is a natural movement of networks to become unnecessarily complicated. \u00a0But there is great value in keeping networks clean and simple. \u00a0Simple networks are easier to manage, more performant and more reliable while being generally less expensive. \u00a0Every network needs a different level of complexity and large networks will certainly need an extensive level … Continue reading One Big Flat Network<\/span>