Where Do You Get Good IT Advice
-
@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.
-
@Romo said in Where Do You Get Good IT Advice:
Increased performance: By reducing the size of the broadcast domain, network devices run more efficiently.
This is one that gets mentioned a lot and it is a benefit of reducing broadcast domain size, but really only on 10Mb/s unswitched networks from the 1990s. In the 2000s once we had switching and stopped having broadcast issues, companies moved to bigger networks rather than smaller. Their statement is technically correct, but contextually misleading. The issue is not so simple as to make this useful. This is used by shops with networking problems to bandaid broadcast problems rather than addressing them.
This also ignores the overhead of the VLANs themselves AND the bottlenecks between VLANs. So introducing problems to fix problems that people should not have.
-
@Romo said in Where Do You Get Good IT Advice:
Improved manageability: The division of the network into logical groups of users, applications, or servers allows you to understand and manage the network better.
It's increased overhead. For 99% of SMBs, it destroys manageability and is used specifically and famously by Cisco VARs to create a management nightmare requiring external, high cost networking specialists to keep the network working. In a giant environment where broadcast domain splitting is required regardless of VLANs, VLANs can be and normally are beneficial from a management perspective. But doing so in an environment too small to benefit from them does the opposite. This shows that Cisco either disregards this market (making their advice wrong without a stated context, especially as this is the majority of the market), doesn't understand networking (likely as reflected repeatedly by their incorrect information) or is actively looking to mislead people to make a sale. This statement on VLANs is just totally untrue as written and the exact opposite of why we recommend against it for most VoIP deployments.
-
@Romo said in Where Do You Get Good IT Advice:
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.
This can be see as general info, or in the context of being listed in why to use VLANs it is marketing. This is a standard marketing ploy: tell what a thing CAN do stated in such a way that the reader assumes that they WANT to do that, even when it makes no sense. In a normal network you would never want to group departments or users, that's only for special cases and enormous environments. The average network does not what this beyond physical groupings by physical device topology. In this context, this is just old fashioned marketing.
-
@Romo said in Where Do You Get Good IT Advice:
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.
Again, true and good to know, but not applicable to the majority case. LAN level security for voice traffic? LAN level security that having a VLAN alone will fix? For the majority of businesses using phones this isn't just unnecessary, it's utterly ridiculous. Cisco doesn't state in this section that this is necessary or recommended, but it sounds beneficial when, in reality, in most cases it is a negative of unnecessary complexity and fragility rather than a benefit of security.
-
@Romo said in Where Do You Get Good IT Advice:
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.
More "this is true" but out of context. Sure, VLANs protect against that, but so does good LAN security. VLANing here is a dangerous bandaid. And if your LAN is so insecure that you cannot control it in this way, your Voice VLAN will have the same risks. It's like telling someone that "if you can't lock your front door, you could lock your bathroom door." But the bottom line is, no one that struggles with one door lock is not going to struggle with the next one, especially when they both use the same locking mechanism. This is a desperate attempt at finding a positive in a generally negative bit of advice. VLANs don't break security, but the security claims about them are heavily just an illusion based on unlikely, illogical sets of circumstance rather than good design or real world practicality. In an ideal world, VLANs offer no security benefit. In a real world, they very rarely do.
Their QoS information is also incorrect and is contextually only about LAN traffic as this is for a LAN deployed, on premises Cisco PBX context. This assumes that there is no WAN to prioritize, which is 99.99% of what prioritization is for. It's a nominally true statement (it's easy and you can apply QoS rules to it, but it doesn't work well and causes you to miss proper QoS, so in practical terms it is anti-QoS.) It prioritizes voice network over other networks, not data over data.
This information is just not up to par for even entry level networking professionals.
-
@Romo said in Where Do You Get Good IT Advice:
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.
And look, we wrap up with "by buying lots of expensive gear, you can overcome the unnecessary problems we just introduced for the sole purpose of selling you all this extra gear."
