Wednesday, November 9, 2016
What is a VLAN – Advice for Server 2012 administrators
What is a VLAN – Advice for Server 2012 administrators
The way that Windows Server 2012 deals with VLANs offers a range of new options to system administrators
VLANs are a widespread configuration in larger or more complex networks, to assist with the flow and segregation of network traffic.
That’s one of those definitions which hides an entire ecosystem under its skirts, as well as complete food chains of misunderstanding and even mis-motivation. To give you some idea of how easy it is to trip up in this field, there are basic concepts which are given different labels by different tribes involved in the same pieces of work on VLAN-enabled network infrastructures. Some people refer to a pipeline with multiple physical links as a “Trunk”; others, as a “Team”. Which one, depends on whether you are a switch wonk, or a server wonk.
As a server administrator and configuration guru, you now have to understand both how your business may have built VLANs into the network fabric historically, and how you should decide to make use of them in an entirely new structure with a much wider range of options. This changes the nature of the job significantly, from the one-dimensional thinking of clicking through a network adapter’s properties dialog box, past a 2D wall-sized whiteboard with multi-coloured pens, and well on to 3D models made from several packets of multi-coloured drinking straws and a half-kilo lump of silly putty, as a method of representing what you are attempting to achieve.
There are broadly three types of VLAN out there. In order of difficulty, these are port-based, tag-based, and protocol-based, each being a tactic for chopping up traffic as seen by a network switch and rather assuming that the devices that send & receive the traffic are pretty dumb in themselves. This “border of stupidity” effect is a line drawn in shifting sands, because over time there have been a series of network based innovations that require the connected hardware to participate in the traffic-management process. Quality of Service, to take one example, works best when the operating system allows all its parts to have some idea of how quickly their traffic will be serviced. Many such services require the client devices to share a configuration setting with their counterparties, even though many other, earlier innovations managed to at least suggest the likelihood that an autoconfiguration process would result in success.
One could argue that VLANs are – for a server admin person – one of those autoconfig, closed-box processes that are better left in the hands of the guy with all those flat, light-blue cables (Cisco device management serial links, switches for the programming of…). Certainly with port-based and protocol-based VLANs this can represent a local minimum of effort.
There is, however, a tidal wave coming to sweep that thinking away, under the general banner of “convergence”. This is an idea people have been discussing for years, and sometimes it can be made to work – the concept that there is no need to run multiple LAN cables, one for each distinct network function such as SANs or VoIP or multicast; that actually it’s cheaper and easier on the brain to converge all those bits of traffic into one pipeline.
The answer to those difficulties is only emerging slowly now, and it is 10Gig Ethernet. It’s quite hard to just upgrade everything to 10GigE and actually fill each faster pipe with traffic – so converged topologies are emerging just as a way of getting best use out of an expensive bit of kit, as well as much better performance out of each of the participating client/server collectives.
via
That’s one of those definitions which hides an entire ecosystem under its skirts, as well as complete food chains of misunderstanding and even mis-motivation. To give you some idea of how easy it is to trip up in this field, there are basic concepts which are given different labels by different tribes involved in the same pieces of work on VLAN-enabled network infrastructures. Some people refer to a pipeline with multiple physical links as a “Trunk”; others, as a “Team”. Which one, depends on whether you are a switch wonk, or a server wonk.
now the switch has moved inside your serverWindows Server 2012 marks the start of Microsoft’s take on software defined networking, or SDN. For the purpose of discussing VLANs, the important thing to bear in mind is that where in the past you might have left all the VLAN fiddling to your switch guru, now the switch has moved inside your server.
There are broadly three types of VLAN out there. In order of difficulty, these are port-based, tag-based, and protocol-based, each being a tactic for chopping up traffic as seen by a network switch and rather assuming that the devices that send & receive the traffic are pretty dumb in themselves. This “border of stupidity” effect is a line drawn in shifting sands, because over time there have been a series of network based innovations that require the connected hardware to participate in the traffic-management process. Quality of Service, to take one example, works best when the operating system allows all its parts to have some idea of how quickly their traffic will be serviced. Many such services require the client devices to share a configuration setting with their counterparties, even though many other, earlier innovations managed to at least suggest the likelihood that an autoconfiguration process would result in success.
One could argue that VLANs are – for a server admin person – one of those autoconfig, closed-box processes that are better left in the hands of the guy with all those flat, light-blue cables (Cisco device management serial links, switches for the programming of…). Certainly with port-based and protocol-based VLANs this can represent a local minimum of effort.
There is, however, a tidal wave coming to sweep that thinking away, under the general banner of “convergence”. This is an idea people have been discussing for years, and sometimes it can be made to work – the concept that there is no need to run multiple LAN cables, one for each distinct network function such as SANs or VoIP or multicast; that actually it’s cheaper and easier on the brain to converge all those bits of traffic into one pipeline.
why when the outside of the box says “gigabit” does all this cheap kit run quite so badly, when the publicity says “ideal for your converged infrastructure?This is a lurking horror to many smaller businesses, whether they are end-users with a simple but diversely-populated LAN, or IT industry SaaS vendors with a mini hosting centre on their hands: Why on earth would the hidden secret society of network device designers ever collectively decide to produce such a thing as traffic types that are antagonistic to each other? And why when the outside of the box says “gigabit” does all this cheap kit run quite so badly, when the publicity says “ideal for your converged infrastructure?”
via
Available link for download
