Where Do You Get Good IT Advice
-
So @Dashrender and I were discussing this offline but it's a good general purpose discussion so figured that it would be a lot more valuable here. The question is, kind of like, "where do IT pros go to get good, general guidance on things?"
That sounds too generic. But the idea is that many IT pros go to places like vendor white papers to get information about how to do their IT. This is a broader industry question.
To go beyond the general case, here is a specific example (but we mean to talk generally here).... where do you go to get information about the applicability of VLANs to VoIP? It seems that everything out there says that you need VLANs.
-
Perfect - now I need a thread specifically about the VLANs and VoIP.
-
So my question to think about is.... where does any industry get its information?
Doctors... would they get their medical guidance from pill makers?
Lawyers... would they get their law information from customers?
Contracts... would they get their building guides from lumber yards?In all of those fields, the people in the field develop best practices as an industry and if a general practitioner needed information on a specific foot surgery they would talk to a specialist that does that surgery, another doctor (just a focused one.) They would not turn to vendors or people outside of the industry for their resources. The lumber yard would supply data about wood, but not how to design a house, for example.
-
@Dashrender said in Where Do You Get Good IT Advice:
Perfect - now I need a thread specifically about the VLANs and VoIP.
So in this example case, which you should post a thread about the answer for that, where would you get information? Let's look...
-
PBX Vendor: they make PBXs, they are not networking specialists. They don't work in IT. They make a product, they don't run operations. Their knowledge, area of authority and interests are not in designing your network. They don't know your needs. (This would be the same as asking General Motors how Dallas should lay out its roads.)
-
Switch Vendors: this is closer, but we have a conflict of interest. Again, this is a product maker, not an operational specialist. While they make networking gear, that's still not the same as operating the gear. This is a better vendor to talk to than the PBX vendor, but still wrong. Especially as any switch vendor that sells gear that supports VLANs has a large vested interest in selling more expensive switches (and selling configuration services through their partners in many cases.) Switch makers that don't make VLAN switches have an interest in suggesting that VLANs are pointless.
-
VARs or Resellers. Same as above, not operational experts. Just sales people with a specific job to push more switch sales and more switch configuration services. Lack of expertise, conflict of interest.
Vendors, conceptually, are the wrong place to turn for IT guidance. It's not that they are bad, or evil, or incompetent, it's that this is not their area of interest or expertise. It's not their job or place to provide that information.
Like other fields, IT develops it's own knowledge, this is what IT does. If we could get this information from vendors, what purpose would there be to IT? The role of IT, and in this example specifically a network engineer, is to understand the factors of the network design, the workloads on the network, the business aspects of the decisions, industry trends, the specifics of different vendor products and to put all of it together into a single plan. No product vendor is tasked with or reasonably even capable of providing this guidance because it's specific to the situation which goes far beyond any one vendor.
-
-
Sure, but the medical example, the ground breaking things are in journal articles to share that information, and get credit for doing it first, etc.
So someone wanting to learn about a surgery thing goes to the journals.
-
So the real answer to "where to IT people learn IT" should come from..... other IT professionals! Specifically those that are aware of your specific needs and that are experts or specialists in the specific arena.
So for VLAN needs, you want a network engineer because it's a network design need and design means engineer. You might want a network engineer with VoIP experience, but the VoIP aspects of that specific question are minimal, general networking knowledge covers it, VoIP is not a special case.
There is always benefits to specific product knowledge, products are sometimes unique. But in the general case, this is a straight forward question about network design and just like any business wanting networks designed should employ the services of a network engineer, so should other IT pros turn to someone with that skill set.
-
@Dashrender said in Where Do You Get Good IT Advice:
Sure, but the medical example, the ground breaking things are in journal articles to share that information, and get credit for doing it first, etc.
So someone wanting to learn about a surgery thing goes to the journals.
But the journals are... medical journals. How often do you see a medical journal written by someone other than a doctor? Not that this is my area, but I'm pretty sure those are doctors teaching doctors. Same as in university, the professors are doctors as well.
-
Now in the VLAN for VoIP example, there can be no generic guidance. As @JaredBusch and I will tell you, the majority case is that VLANs are not necessary, but that is only the majority case. There are certainly reasons for needing VLANs and just because a company has VoIP does not mean that they won't need VLANs. But having VoIP is not a reason on its own to even suggest a purpose for VLANs. So, just like you did before looking at VoIP, you need your network designed to meet your business' needs in the general sense. There are many factors that go into this.
This is what creates IT jobs - what we do is complex and it is an aspect of the business. We are not like mechanics that simply repair existing, established products. A mechanic working on a Chevy Spark can look in a Chevy Spark manual and learn every bolt and piece and can follow directions and repair or replace everything on the car from a missing plug to rebuilding the entire car. There is nothing like this in IT, in fact, work that gets closer to that is not IT but bench (swapping RAM in a desktop, replacing a hard drive.)
In IT, we work on business systems which are made up of complex mixtures of software, hardware, networks, users, configurations, versions and more. Each business' network is extremely unique. We can never go in with a manual to the "business" and simply "replace the broken part." IT is nothing like that. So because our networks are unique, there is no vendor to turn to that has a manual on "how to do IT." Once that exists, IT as a profession is over and bench will replace it, over night. As long as IT exists, vendors will provide us with important information about their own products, but knowledge of IT has to come from the IT field.
-
Right, so where is IT stuff written by IT people that you can do searches on/for? Maybe there's a publication I'm just completely unaware of that I should be using as research.
-
@Dashrender said in Where Do You Get Good IT Advice:
Right, so where is IT stuff written by IT people that you can do searches on/for? Maybe there's a publication I'm just completely unaware of that I should be using as research.
That's specifically what places like ML seek to address from one angle (peer review) and what SMB IT Journal seeks to hit from a published paper perspective. However some things, like VLANs for VoIP are difficult to publish on because you are forced to effectively just publish the negative case (e.g. "Why You Don't Necessarily Need a VLAN for That, But Still Need Due Diligence.") Know what I am saying? Because it isn't like there is a one situation fits all, all a good paper would do is dispute the vendors and sales people making the claim that one situation does fit all (coincidentally, the one that costs the most.) But we already know from the more general "never get advice from resellers or vendors" and "do get advice from focused IT pros in the field" and "vet discussions in a peer review group for your specific situation" to ignore vendor white papers and such. So making a specific case industry white paper on it is, odd, at best.
What is more useful is just good education in general about where to get good info (hence this thread) and how to avoid myths that get repeated and how to look for information source locations (how vendors got the notion of VLAN into the minds of people who aren't network engineers.) And then, threads that ask about VLANs for specific scenarios. Is a VLAN appropriate for you? We can't answer that in a white paper, we need data that a white paper can't consider.
-
Now something that we can teach, though, is critical evaluation. So in the VLAN case we can ask questions like:
- What is the standard function of a VLAN (security and management.)
- What is the reason that we assume we need it (QoS.)
- Do VLANs provide QoS (no.)
- Who is promoting the needs for VLANs (vendors with money to make, resellers with money to make, SMB shops that don't have dedicated network engineering resources to evaluate the situation.)
- Who that is an appropriate guidance resource (PBX engineers that are not resellers, Network Engineers) that is recommending VLANs for VoIP (none that we know of.)
If we start without the expectation that the vendors are authoritative and must be disproved, it's actually pretty easy to establish that there is likely not even a reason for VLANs to have entered consideration in most cases. In this scenario, the original question was something like "Since so many vendors recommend VLANs, where do we find white papers saying that we don't need them?"
The reason that they are not found is because there is no need for them, the IT industry doesn't have general guidance pointing anyone to VLANs so there is nothing to dispute. That sales people recommend VLANs anytime that they can is irrelevant. Car salesman always think you need the DVD player and pop up displays, too. But we know that that is just sales, we don't need Car and Driver to tell us that the DVD option is overly expensive and only useful if you have kids.
-
There are other important things that we can learn, like how to spot IT myths that get repeated but don't stand up to a test of "but why?" Like that thread we saw on SW today, the person demanding VLANs stated goals that his VLANs were not supporting, in fact they were breaking that as expected. Instead of realizing that VLANs were not needed, he switched his goals. Because under the hood, his goal was billable hours (he was a vendor, it turned out, and not representing the customer's needs) and not QoS as he had stated. He moved the goalpost to maintain what he actually had wanted.
Things like always needing (or even often needing) VLANs for VoIP is much like Facebook's Fake News. It's trivially easy to repeat trite IT "rules of thumb" as if they are true. Tons of people, and it is especially true in small shops where there is often no one to question poor IT decisions, rely on memorizing simple rules instead of learning how things work and the factors that are needed to evaluate needs. This allows people to not pay for advice, and not take the time to learn different area, but still provide good sounding advice on to businesses. This often works because there is no one verifying when things are plausible.
VLANs for QoS are pretty obviously not plausible for network engineering. Even if you have a VLAN, the data on the VoIP VLAN is mixed and you want QoS on the audio, not the control traffic. So even with a VLAN, you want QoS elsewhere. Especially important as you find that most shops (that we see) with VLANs accidentally terminate the VLANs and drop the QoS before it has a chance to get applied!
-
do you have any tags on this post?
-
@Dashrender said in Where Do You Get Good IT Advice:
do you have any tags on this post?
Nope, any suggestions?
-
Advice might be good, or IT advice... but advice by itself will be easier to find.
-
To go beyond the general case, here is a specific example (but we mean to talk generally here).... where do you go to get information about the applicability of VLANs to VoIP? It seems that everything out there says that you need VLANs.
I guess since Cisco has been the one always recommending using a voice vlan for increased security and better qos most people have been following their recommendations without really thinking.
From their documentation
VLAN Concepts and Configuration
After the IP phone has received power, it must determine its VLAN assignment. Because of security risks associated with having data and voice devices on the same network, Cisco recommends isolating IP phones in VLANs dedicated to voice devices. To understand how to implement this recommendation, let's first review a few key VLAN concepts.
VLAN ReviewWhen VLANs were introduced a number of years ago, the concept was so radical and beneficial that it was immediately adopted into the industry. Nowadays, it is rare to find any reasonably sized network that is not using VLANs in some way.
VLANs allow you to break up switched environments into multiple broadcast domains. Here is the basic summary of a VLAN:
A VLAN = A Broadcast Domain = An IP Subnet
There are many benefits to using VLANs in an organization, some of which include the following:
Increased performance: By reducing the size of the broadcast domain, network devices run more efficiently.
Improved manageability: The division of the network into logical groups of users, applications, or servers allows you to understand and manage the network better.
Physical topology independence: VLANs allow you to group users regardless of their physical location in the campus network. If departments grow or relocate to a new area of the network, you can simply change the VLAN on their new ports without making any physical network changes.
Increased security: A VLAN boundary marks the end of a logical subnet. To reach other subnets (VLANs), you must pass through a routed (Layer 3) device. Any time you send traffic through a router, you have the opportunity to add filtering options (such as access lists) and other security measures.
Understanding Voice VLANs
It is a common and recommended practice to separate voice and data traffic by using VLANs. There are already easy-to-use applications available, such as Wireshark and Voice Over Misconfigured Internet Telephones (VOMIT), that allow intruders to capture voice conversations on the network and convert them into WAV data files. Separating voice and data traffic using VLANs provides a solid security boundary, preventing data applications from reaching the voice traffic. It also gives you a simpler method to deploy QoS, prioritizing the voice traffic over the data.
One initial difficulty you can encounter when separating voice and data traffic is the fact that PCs are often connected to the network using the Ethernet port on the back of a Cisco IP Phone. Because you can assign a switchport to only a single VLAN, it initially seems impossible to separate voice and data traffic. That is, until you see that Cisco IP Phones support 802.1Q tagging.
The switch built into Cisco IP Phones has much of the same hardware that exists inside of a full Cisco switch. The incoming switchport is able to receive and send 802.1Q tagged packets. This gives you the capability to establish a type of trunk connection between the Cisco switch and IP phone, as shown in Figure 3-6.
-
@Romo said in Where Do You Get Good IT Advice:
To go beyond the general case, here is a specific example (but we mean to talk generally here).... where do you go to get information about the applicability of VLANs to VoIP? It seems that everything out there says that you need VLANs.
I guess since Cisco has been the one always recommending using a voice vlan for increased security and better qos most people have been following their recommendations without really thinking.
Right, a vendor. And not just a vendor, a vendor that makes a product focused on a market size where the scale guarantees a need for VLANs already for other purposes. And a vendor that uses different protocols from the rest of the market. So reasons that that is bad would be:
- It's a vendor and not a valid source of this guidance from the VoIP perspective.
- It's a vendor and a semi-valid source of this guidance from the network perspective, but only semi and only sometimes and not for many of the reasons below.
- A vendor with gear to sell.
- Equipment only meant for companies of large size.
- A vendor with a track record of reckless guidance (their engineers once told a SpiceCorps in Houston that you need 14Tb/s to the desktop to watch YouTube, Cisco doesn't even make gear that fast today and this was five years ago.)
- A vendor whitepaper - so automatically invalid for this kind of guidance, they have not taken the business needs or network design into account which means that giving the advice in a vacuum is reckless.
- Not an IT vendor.
HOWEVER.....
Even with all of that, Cisco does NOT recommend VLANs for QoS, but for security. A different issue. One that should worry us, why is Cisco depending on LAN based security in this modern age? That's a problem with Cisco phones that they are trying to address with their switches. This is good advice, in context. But the context is everything.
-
@Romo said in Where Do You Get Good IT Advice:
VLAN Concepts and Configuration
After the IP phone has received power, it must determine its VLAN assignment. Because of security risks associated with having data and voice devices on the same network, Cisco recommends isolating IP phones in VLANs dedicated to voice devices. To understand how to implement this recommendation, let's first review a few key VLAN concepts.
Cisco has security concerns about their phones, so they recommend VLANs as an additional cost to fix them. That's the base context here. This isn't a VoIP recommendation in any way, this is a Cisco phone issue. No one should have taken this advice and applied it to QoS, non-Cisco equipment, etc.
-
@Romo said in Where Do You Get Good IT Advice:
VLANs allow you to break up switched environments into multiple broadcast domains. Here is the basic summary of a VLAN:
A VLAN = A Broadcast Domain = An IP Subnet
This information about a VLAN is wrong. You can subnet without VLANs, you can VLAN without subnets. Unrelated concepts.
-
@scottalanmiller said in Where Do You Get Good IT Advice:
@Romo said in Where Do You Get Good IT Advice:
VLANs allow you to break up switched environments into multiple broadcast domains. Here is the basic summary of a VLAN:
A VLAN = A Broadcast Domain = An IP Subnet
This information about a VLAN is wrong. You can subnet without VLANs, you can VLAN without subnets. Unrelated concepts.
It could be good practice in most cases, but like @scottalanmiller said: Unrelated.
