2

We are currently looking at VoIP for about 70 users. We're getting a bit confused regarding the choice to run a 'converged' network (VoIP running on the same cables and switches as data) versus 'separate' (separate cabling and switches for data and VoIP traffic). We understand the need to use proper gear so that we can manage QoS, VLANs, supply PoE if necessary, etc., although it's fair to say that we don't understand the related details or implications.

We are not doing this ourselves, we just want to do due diligence on vendor recommendations. Naturally, we have different recommendations from different vendors. The vendors are telling us why they think their recommendation is better, but we're having some difficulty putting it all together so that we can choose what's best for us.

Most of our users are connected to the network via 'direct' Ethernet connections. About 15 users are in a separate building supplied by fiber, but they are ultimately on the same network. There is currently no VLAN, but we understand the benefits of VLAN if we decide to go converged (it allows use to go 'separate' without the need for physically separate switches and cables). About 15 of our users are remote workers in various parts of the country and we have another 10 or so road warriors. I don't know if it matters, but all remote staff, most road warriors, and some 'stationary' workers are on Terminal Services and we expect to eventually have about 2/3 of our staff on Terminal Services.

Most of our current concern regarding this is associated with two factors: soft phones and bandwidth to the desktop. As we understand it, opting to use a large number of soft phones requires that we deal with the various convergence issues even if we do have hard phones on a separate network. Is this true? Is it also true that the only sensible way to keep soft phones on a separate network would be to supply each user with 2 network cards?

As far as bandwidth to the desktop, it's our understanding that the standard approach in converged networks is to connect a hard phone to the network then connect the user's computer to the phone. At present we provide gigabit to each user and the cost of phones that can deliver gigabit to the computer is so much higher than 100 mbit that we'd actually be cheaper to run separate networks (assuming most users get hard phones).

There are some things we already know. We know that losing a switch in any configuration of converged will take down both data and voice, but we also know that having a pre-configured spare will keep our downtime to little more than the length of time it takes to troubleshoot and locate the failed device. We know that we have to do a good job of the network to go converged and that we may have to do more than just replace some switches (replacing switches is not really an issue, because that needs to happen anyway for other reasons). We have looked at articles like this and they're helpful as far as understanding general concepts but a bit light on specifics.

Update 1: We're not running a call centre. Based on our telco's reports, we have no blocked calls with 10 lines. Those 10 lines serve about 50 people at our headquarters. I don't remember the line count recommendations (I'm working from home today), but there was certainly no need to increase the number of lines.

Update 2 - query: I haven't seen anyone comment on the implications of the fiber link we run between two buildings. Is that because it has no bearing on the issue? Is it even possible to run separate networks in this case? As far as I can tell, we are multi-mode capable.

Update 3 - Why I chose plz: Every response was very useful, but ultimately, plz led us to consider things that we had not already considered. We have already some of what we learned here to get more information from our vendors. They're coming back with better articulated reasons for their recommendations, so I think we'll be okay now. As it stands now, converged (with VLAN, etc.) looks most likely given our current infrastructure, call volume, and the preference for softphones.

1
  • interesting question, i'm looking forward to see answers comming from both 'camps'. i run without problems voip over same data network, without separate vlans, without qos. not the best practice, but a cheap and good-enough solution for now.
    – pQd
    Sep 30, 2010 at 18:37

3 Answers 3

5

A lot of this depends on the bandwidth that your phone system is going to use - if it's a call center with hundreds of people on the phone simultaneously you'll have a higher need for a separate network than an office of hundreds who just want phones on their desks but aren't heavy users. A conservative (as in, "way more than is really used") estimate is 128kbps per simultaneous call, or 8 calls per megabit, so gigE can do approximately 8000 simultaneous calls (okay, a little less due to overhead, but that's the right order of magnitude). So it's unlikely to be a bottleneck. And as long as you have QoS so that big downloads won't affect your phone traffic you should be fine.

Something you don't address is the Power Over Ethernet (PoE) angle - PoE switches are a significantly more expensive (both to buy and to run) than their non-PoE counterparts. One nice feature of PoE is that a single UPS on the switch keeps all the phones running during a power outage.

What I've done in the past is: run a PoE and a non-PoE port to everyone's desk. The PoE is labeled 'Phone', the non-PoE is 'data'. This preserves data speeds for the user's computer, gets the aforementioned power redundancy for the phone, and allows me to (eventually, if needed) separate out the networks more.

So I guess what I'm saying is: don't bother with 'software' non-convergence, but do bother with separate networks where the hardware matters. If the hardware's going to be the same though (ie. you're running all PoE or all-non-PoE switches) then a converged network should be fine.

6
  • Agreed, particularly on the POE. Depending on the vendor, POE 100MBs ports can be much cheaper than POE GB ports so separate POE switches & runs are cost effective while still providing GB to the desktop.
    – Ed Fries
    Sep 30, 2010 at 23:38
  • +1 - hard data followed up with personal experience. Oct 1, 2010 at 2:20
  • @pjz: Thanks for bringing my attention to the costs of PoE. I'll certainly follow that up, but it was my impression that PoE would be less expensive than adding power adapters to every phone. Also, we're not running a call centre. I'm working from home today so I don't have all the numbers, but I do remember that our telco's analysis of our current call volume showed 0% blocking on 10 lines serving 50 people at our headquarters.
    – user39986
    Oct 1, 2010 at 13:00
  • @Ed Fries: Thanks for pointing out that we can probably get away with 100Mb PoE which could have a big impact on the cost.
    – user39986
    Oct 1, 2010 at 13:04
  • @pjz: Does the fiber connection between buildings affect our ability to go with separate networks? As far as we can tell, we are multi-mode capable.
    – user39986
    Oct 1, 2010 at 22:49
2

Converged versus the non-converged network. I personally would recommend splitting the VOIP and data onto separate physical networks… the non-converged option. The reasoning for this is, in my opinion, the cost differences are really not all that significant and it provides a couple of advantages.

First advantage is, it doesn’t matter what your data users are doing, it won’t impact your phones. Between bandwidth hogs, users who get infected with viruses, physical malfunctions, and/or user maliciousness there are a lot of possible ways for your data users to impact your VOIP users if they share any infrastructure. Even if you are applying QoS policies, if you have a user blasting out 100mbps of Ethernet traffic, it can overload switches processors, set up an environment Ethernet collisions are very likely to occur on, etc. In my mind, you run a second set of cables, you throw in a second set of switches and you don’t have to worry about that….

Second reason is security. It is not that difficult for a savvy user to go out and capture VOIP traffic and reconstruct phone conversations they really shouldn’t be listening to. Yes, this is mitigated to a large degree by using separate VLANs, but there are some techniques that let you hop from one VLAN to the other… having the traffic on two entirely separate physical networks limits that. Having two separate networks won’t prevent this, but in my opinion, since they would have to physically connect to the second network to snoop, it takes care of a lot of the “was he intending to do this?” question.

Third, in my opinion it is really nice to have the networks not converged from a troubleshooting standpoint. If you have nothing but VOIP calls going across the network, then you don’t have to rummage through page after page of wireshark captures looking for the traffic you want… yes, this is what Find is for, or filters are for, but in my opinion VOIP is tricky to troubleshoot and as simple as you can keep the environment you are troubleshooting in, the better off you will be.

The soft phones are going to pose a problem, and there is not a real good work around for those. You should be able to capture their traffic and apply QoS policies to it to improve it’s chances on your data network, but really, there is only so much you will be able to do with these. I like soft phones, they are neat gadgets, but I would not recommend using one as a primary phone for someone that has to have a reliable phone. I suspect you could come up with some solution with 2 NICs in each machine that uses a soft phone client, but that still won’t protect you from issues like choppiness on a soft phone call because the PC’s CPU is chewing on opening a large file.

I would recommend testing out the soft phones before you decide to implement them, make your vendor install one on a machine and then hammer the CPU on that machine and see if the quality degrades past what is acceptable to you.

I would strongly advise against using one cable for the voice and the data, I know that is supposed to work, but since those are not on separate broadcast domains, if the PC is transmitting heavily you will have problems with the phone accessing the media.

Another, secondary reason I like separate networks is, in case you do have some sort of catastrophic melt down on one of your networks… you have a switch blow up for instance… you do have a second network sitting there you know works that you can sometimes temporarily draft into service to cover you until you get that other network fixed… I know that somewhat goes against all my previous arguments, but if it gets users back up and running, I am okay with breaking my own rules

About the only argument I can think of that carries any water for going with the converged network versus the non converged is an ease of management argument. While I am all for keeping your network as easy as possible, I don’t feel the extra network adds complexity to the management of the network.

5
  • You've made an excellent case for separate networks. Our key concerns regarding converged networks are related to configuration, troubleshooting, and maintenance. We wonder if it's easier to look after 2 special-purpose networks than 1 converged network. Our main issue is with soft phones. With soft phones, we're forced to deal with at least some convergence, but as we get deeper into Terminal Services, soft phones would seem to be less suitable and probably out of the question.
    – user39986
    Oct 1, 2010 at 13:19
  • Does the fiber connection between buildings affect our ability to go with separate networks? As far as we can tell, we are multi-mode capable.
    – user39986
    Oct 1, 2010 at 22:49
  • @Ron Porter - fiber does not affect that. you put two vlans on the fiper, shape data vlan to leave enough room for voip and you are good to go. or use cwdm...
    – pQd
    Oct 2, 2010 at 6:39
  • ethernet collisions in a switched environment are fairly rare, I thought? And snooping over a switch typically requires port-mirroring, no?
    – pjz
    Oct 4, 2010 at 19:56
  • yes, switched networks have much fewer problems with collisions, but it doesn't completely preclude them from being a problem. Broadcast traffic gets transmitted to all ports in a switched network Oct 6, 2010 at 22:05
1

IMO, you need to think about how this will be managed and how it will integrate in your organization. Do you have multiple networking teams with different management, or one team?

  • In a big environment, you may have different groups for Telecom, Client Networking and Data Center networking. If you do, and plan to keep that arrangement, that might be a driver for using separate VLANS.
  • Are you going to use desk phones, soft phones or both? If you're going to use soft phones, that's a vote towards converged.
  • Do you have intentional isolation between client segments of your network? IP Phones want to talk to each other. If you want to preserve that isolation, a phone VLAN might make sense.

Articles tend to be generic because many people have positions that they hold out of a religious-like fervor rather than based on fact. There's no one answer.

For your case, it sounds like you philosophically like terminal services and are leaning in that direction. But at the same time, you have road warriors who are bringing in laptops. I think that's a great position to be in, because a huge chunk of your end-users are on terminal services, and you can model their bandwidth requirements pretty easily and build a converged network that has enough capacity to meet your needs.

pjz's suggestion to pull PoE and non-PoE makes a hell of alot of sense too, as it gives you the flexibility serve your road warriors AND the thin client guys who need hard phones.

3
  • Our entire IT group consists of 1 manager, 1 programmer/administrator (me), and 1 desktop/network administrator. We rely on vendors and contractors for stuff that goes over our head, but we try to learn enough to make sure that we're not led astray and to ensure that we can handle day to day tasks. We were initially leaning toward a large number of soft phones, but quickly realized that was in conflict with our plans for Terminal Services. Also, others here have pointed out that soft phones may not perform well under some circumstances.
    – user39986
    Oct 1, 2010 at 13:11
  • Lucky you! Political issues are always harder than technical ones. I'd do what the vendor proposes that you do, Oct 3, 2010 at 1:21
  • Doing what the vendor proposes is where the challenge arises. We've gone far enough through the process to get fairly firm recommendations and find that we still have some vendors proposing converged and others separate. What's got us a bit edgy is that the members of each camp clearly see their recommendation as the natural one.
    – user39986
    Oct 3, 2010 at 18:33

You must log in to answer this question.