No announcement yet.
  • Filter
  • Time
  • Show
Clear All
new posts

  • Put Server in Voice or Data VLAN

    Up to this point our system has been small with not much need to implement VLANs and QoS. We are about to add 80+ phones, so we are laying out the plan to implement VLANs and QoS. Our Server is currently on the native VLAN which will be the data VLAN. We plan to isolate the phones & the voice switches in a voice VLAN.

    My question is this: should I go through the tedious process of changing the IP on the server so that it is in the voice VLAN? My thinking in doing this would be that the switches and phones can communicate with the server with out going through the routers/L3 switches. Then the only traffic that would travel across VLANs would be Call Manager traffic. Can Any one share their experiences and thoughts on which would be the best? Leave the Server on the Data VLAN or move it to the Voice VLAN? Thanks!

  • #2
    FYI, here is some information from a tech tip in ShoreTel's KB. Is there some particular reason you wish to do VLANs?

    "My customer thinks they want to use a separate VLAN for Voice. Is that a good idea? Does ShoreTel support separate VLANs for voice? Do they recommend it?"

    ShoreTel doesn't need VLANs. Our voice quality is not improved with VLANs. VLANs complicate a LAN design significantly. And, using an external router to connect and route between the Voice VLAN and Data VLAN can actually increase latency producing worse voice than without VLANs.

    Suggestion: only use VLANs in these 3 circumstances:

    A) The customer already has them, they like them or they really want VLANs and they don't want to be talked out of them ("It's a feature in my very expensive L3 switch and, by golly, and I want to use it!")

    B) They have been told by Cisco, who regularly requires customers to use VLANs in order to achieve high-quality voice, that VLANs are a "must." (Cisco uses Private VLANs, Trusted VLANs, Native VLANs, Shared VLANs, Community VLANs, Protected VLANs, etc. What a mess!) If the customer still thinks VLANs are the "only way to go," don't fight it, stroke their karma and deploy ShoreTel VoIP on VLANs. We work great on VLANs!

    C) The customer wants added security, say, to prevent voice "sniffing" (how about upgrading to ST6 [or better] w/ encryption RTP media, instead!) or wants to separate the VoIP devices off the data LAN to avoid Worm attacks, Denial of Service (DoS, DDoS) attacks, etc. In my opinion, this is the only GOOD reason to do VLANs.


    • #3
      Also note that you can do QoS without VLANs by using the Diffserv / ToS setting and configuring your routers.


      • #4
        Well... I swear we were told in our "official" ShoreTel class that a separate VLAN for voice AND QoS were the best practices. We're also doing VLANS for a couple other things... Public Internet Access and Security system, so we're already setting them up.

        Where did you find that document? I can't seem to find it in the KB.


        • #5


          • #6
            Originally posted by Palitto Consulting View Post
            You must have to be a Partner to view it. I got an access Denied error. I'm an enterprise support customer.


            • #7
              That would likely be the case. I do have a partner-level login and it is addressed to ShoreTel Partner Engineers.


              • #8
                UGH, Shoretel App Notes (especially a dated on that like one) are not always right. The best practice is certainly to isolate the broadcast domain for voice versus other traffic.

                It is true that you don't need to seperate broadcast domains to prioritize RTP streams (they are tagged with a DSCP bit and any enterprise grade switch will handle this appropriately).

                That only addresses the RTP stream though. Shoretel is STILL susceptible to other traffic causing issues with signaling between all of the devices. I've seen PLENTY of times over the years where environments were not segmented and some type of funky traffic (typically broadcast) will freak out the phones. I've even seen it hard lock all of the handsets. You can do some fun things if you point certain types of traffic directly at the handsets as well.

                So no, it is not required to prioritize RTP steams but it can provide added benefits and peace of mind for other scenarios that can occur in a data environment. This is also why we isolate broadcast domains for other mission critical solutions (i.e. storage, vmware, etc.).


                • #9
                  cburgy do you have any thoughts on my original question? If we do VLANs, which VLAN should the HQ server be in?


                  • #10
                    We always put ours in one of the voice vlans (depending on the size of the installation, we segment a control vlan for SG switches and servers).


                    • #11

                      Anyone else able to share how there server is setup in VLANs? Data or Voice side?


                      • #12
                        I would also recommend putting the any system servers in a voice VLAN. Whether you are small enough to only have one or have many VLANs provide a valuable means of shaping traffic beyond just giving priority (what DSCP provides). I would agree that the KB cited is vastly out of date, any core enterprise switch worth using routes well enough internally that their concern about routing is unwarrented. I only worry about that sort of thing when someone insists on using low end stuff (dell, netgear, sonicwall...). The voice VLAN is the place to be.


                        • #13
                          I have always tended to put the server with the client's other servers. In a seperate VLAN or wherever. What I consider a more inportant question, is where to put the switches.
                          I try to always place them in the same VLAN as the phones they are supporting. There is a lot more traffic between switches and phones vs server and phones. I would also agree, the ShoreTel KB articles can sometimes leave a bit to be desired... I have always liked the idea of segmenting the broadcast domains based on purpose and criticality of the data.
                          It makes sense to me.