Connecting 2 sites over Layer2

[Escapo-IT]

Over the next month we will be installing our first Shoretel system, no experience with other VoIP systems, so please excuse my ignorance.

We have recently bought a second building located about 400m from our HQ. Because of the proximity we have opted for an RF link between the 2 sites (after a fiber link was ruled out by CFO), this will provide us with 50Mbit FD bandwidth with QoS capabilities. This RF link can also act as a Layer2 bridge so will not have to worry about routing, we can just look at this as a LAN extension.

Now in the install guide I read that it is recommended (needed ?) for different sites to be on different subnets so that the phones log on to the correct, local, voice switch. Is this geared towards people connecting sites via Layer3 or is this also valid for our situation ? We will have a voice switch on the secondary location because we need some analog devices and it would make sense for the phones there to use that switch.

I'm just trying to get my head arround the whole networking site of thing, we will be deploying this on new Extreme Networks switches. (Yes I have a lot of reading still to do !!)

Any and all input is appreciated and please excuse my spelling, I am not a native speaker.

Thanks,
Tom.

[eazeaz]

Sites

If your connection is 50MB full dupex, AND is rock solid, AND has good QOS to prioritize voice traffic, then a separate "site" for the other building is not necessary (in my opinion).

You just have to keep in mind during the design, that if that RF link goes down, the "remote" building is pretty much screwed.........

[400degreez]

The main thing is to make sure you have good RF equipment. Being that Shoretel is sensitive to packet loss you want something that is geared for Shoretel. Pound for Pound, Ruckus is you best look. They are Shoretel certified and believe it or not, they work. The secret is the multiarray, beam forming antenna. Price wise they are very competitive too. Give them a look and I promise you and the boss will thank a brother.

400Degreez...first name Ever, last name Greatest!

[Contractor]

Use different subnets and route between the two sites. Give the 'remote' site its own trunking and put a DVM at the 'remote' site.

Its tempting to go cheap here, but you won't like the results.

[cburgy]

How many devices (computers, printers, phones, etc) are going to be in this second building?

How many in the first? Have you setup VLANs in your first building?

[Escapo-IT]

Thank you all for the responses.

If your connection is 50MB full dupex, AND is rock solid, AND has good QOS to prioritize voice traffic, then a separate "site" for the other building is not necessary (in my opinion).

You just have to keep in mind during the design, that if that RF link goes down, the "remote" building is pretty much screwed.........

Well, it an RF link so it is never going to be rock solid, but our equipment has been used over a lot greater distances without issue so we are hoping the proximity of the 2 sites will help the uptime. You always have to allow for the weather, so we "plan" for 2 outages a year. We have a 3hr on-site SLA and the vendor is located about 30 minutes from us.

It would be nice if during an RF outage phones on the second site remained functional for internal calls because an entire, sort of selfsufficient, business unit will be located in the second building. What would be needed for this scenario ?

The main thing is to make sure you have good RF equipment. Being that Shoretel is sensitive to packet loss you want something that is geared for Shoretel. Pound for Pound, Ruckus is you best look. They are Shoretel certified and believe it or not, they work. The secret is the multiarray, beam forming antenna. Price wise they are very competitive too. Give them a look and I promise you and the boss will thank a brother.

400Degreez...first name Ever, last name Greatest!

Thank you for the suggestion but we have already bought the RF equipment. We will be using "AirMUX" from RAD technologies, originally built for the Israeli army and adapted for civilian use. The vendor had good references of which some were also using VoIP, no ShoreTel though ... they do not really have a presence yet here in Belgium.

Use different subnets and route between the two sites. Give the 'remote' site its own trunking and put a DVM at the 'remote' site.

Its tempting to go cheap here, but you won't like the results.

Thank you for your input, why is it better to go Layer3 instead of a "simple" LAN extension ? I get what you are saying about the DVM though, if VM catches on with our users (they do not have VM right now) then this might indeed become a neccesity.

How many devices (computers, printers, phones, etc) are going to be in this second building?

How many in the first? Have you setup VLANs in your first building?

About 20 PC's, 15 phones, 4 printers. So this is a very small environment, no power users either just some light office work and SAP. Knowing our users most won't even though the PCM, they are not very tech-savvy to say the least.

First building houses about 70 PC's, 80 phones, 10 printers. We do have VLAN's in place and will be creating an extra VLAN dedicated to Voice and applying some QoS on that VLAN. The initial idea is to just stretch this VLAN over to the second building via Layer2.

[cburgy]

Merely just bridging the connection across is really quite inefficient. Extending that network will also extend all of your broadcast and any multicast traffic across the link. This is why you typically see locations being routed instead of bridged. You have a large enough network where the broadcast domain would be of concern over this link.


Another important consideration to take into account is QOS. While the equipment may support QOS, you really need to understand exactly HOW it supports QOS. Is it 802.1P? Does it implement it in hardware? How many queues then?

This is yet another reason why a routed infrastructure is typically implemented. By putting routers on each side, I can leverage significant control on the egress of each end and ensure quality of voice and any other traffic will not degrade.

Shoretel implements QOS at Layer 3 via the TOS bit. When you set the bit in Director, it alters a field in the IP header. If you are bridging the connection and your gear can not perform QOS by inspecting the IP header, you effectively have no QOS. It doesn't do any good to mark the IP header if equipment is just looking at the ethernet frame header (which would then be done with 802.1P).

My vote... Toss a couple Juniper SRX210s on each end of the link and route. You can then perform all the QOS you'll need and you'll get more throughput out of the link by isolating it from broadcast traffic.

Also, toss a SG30 or SG50 at the other site and set it up as a logical site in Shoretel. That way you can implement surviviability and plug a POTS line in for backup / 911.

[Contractor]

L3 will allow you to encrypt data if you want to, it gives you more control of the traffic, and as cburgy said, you can enable QOS a lot easier. With different subnets at each site, its easier to monitor your IP traffic as well.

Put a switch and a couple of phone lines (POTS) over at the remote site along with a DVM. Nothing will make your life more miserable than coming to work every day and hearing users moan and groan about how $hitty the phone system is and what an idiot you were for choosing it. Even if you choose to spend the money after the fact and get a DVM and local trunking, you will have empowered the whiners and complainers in your company. If you spend the money up front, train the users and do the install correctly, ShoreTel will make you a rock star. If your boss complains, tell her you could have chose Cisco and paid twice as much for less of a system.

[Escapo-IT]

Well you have certainly given me some food for thought !

The RF antennas will be hooked up to an Extreme x450e on one end and to an Extreme x250e on the 'remote' end, both of which do static IP routing I believe ... so we should be OK on that front.

We have allready purchased an SG40 (ShoreTel - ShoreGear-40) for the second building because we needed to hook-up soms analog equipment and were planning to install a seperate POTS line for 911 purposes, not connected to the ShoreTel.

Shoretel implements QOS at Layer 3 via the TOS bit. When you set the bit in Director, it alters a field in the IP header. If you are bridging the connection and your gear can not perform QOS by inspecting the IP header, you effectively have no QOS. It doesn't do any good to mark the IP header if equipment is just looking at the ethernet frame header (which would then be done with 802.1P).

Now other then the basic premise I don't know anything about QoS so please bear with me here. I've read that you can set the DiffServ (aka TOS, aka DSCP, ...) bit in Director and that the recommendation is 184, but I was under the impression this was not needed because we will seperate anything voice related (phones, director, switches, VM) into a VLAN and giving that priority ? Is this not correct ?

One thing I did think of was PCM traffic, so I will also have to device an ACL (dest. IP = director server) to give that traffic some priority because of course this will originate from outside the voice VLAN.

I do not know exactly how the RF implements QoS and the manuf. does not have any manuals listed on their website, I will ask our vendor. You are right this is a very important factor which I almost overlooked, thanks for pointing it out.

I was really hoping to get a fiberlink but there were "cost issues" ... aren't there always

[Escapo-IT]

Now other then the basic premise I don't know anything about QoS so please bear with me here. I've read that you can set the DiffServ (aka TOS, aka DSCP, ...) bit in Director and that the recommendation is 184, but I was under the impression this was not needed because we will seperate anything voice related (phones, director, switches, VM) into a VLAN and giving that priority ? Is this not correct ?

Any further input regarding this question ? Thank you.

[Jason Learmouth]

...but I was under the impression this was not needed because we will seperate anything voice related (phones, director, switches, VM) into a VLAN and giving that priority ? Is this not correct ?

Any further input regarding this question ? Thank you.

Not entirely correct because while you can (and should) give priority to the voice VLAN, not all traffic in that VLAN is voice. There is signalling between switches and phones that needs to be treated differently than voice packets. Also, the ShoreTel server is normally on the voice VLAN as well so there is all the Call Manager data traffic and possibly email (SMTP) traffic between HQ and DVM servers. On top of that these are Windows servers which means they are going to be quite chatty anyway - Domain stuff, Updates, File share, etc.

You still need to do QoS on the WAN gateway at the packet level, even if you are using VLANs.

My general comments on your setup are that you should be using Sites within ShoreTel to separate the two networks, especially since you have trunks at each site. A DVM is proabably a good idea if there are enough users to justify it - if you can't swing that then I'd probably consider a local FTP server at the second site for when phones and switches upgrade or reboot.

Good luck,

[Escapo-IT]

Thank you Jason;

Not entirely correct because while you can (and should) give priority to the voice VLAN, not all traffic in that VLAN is voice. There is signalling between switches and phones that needs to be treated differently than voice packets.

Oh I see, the plot thickens ! Will setting the TOS bit in Director cause all the traffic between ShoreTel components to be marked or is the system intelligent enough to only mark actual conversations ? In other words can I get away with prioritizing this inter-VLAN traffic based on TOS 184 of will I have to set up portbased ACL's to differentiate realtime (voice) from signalling and such ?

Also, the ShoreTel server is normally on the voice VLAN as well so there is all the Call Manager data traffic and possibly email (SMTP) traffic between HQ and DVM servers.

Oddly enough I had thought of this, so I was thinking of creating a port/destination based ACL to prioritize traffic from the CM application to HQ/Director so voicemail playback won't end up being choppy.

My general comments on your setup are that you should be using Sites within ShoreTel to separate the two networks, especially since you have trunks at each site. A DVM is proabably a good idea if there are enough users to justify it - if you can't swing that then I'd probably consider a local FTP server at the second site for when phones and switches upgrade or reboot.

I'm going to take your, and the other contributors, advice on this and use different subnets for both sites. A local server for the second site is not feasible at present but I will put this high on my wishlist !

Thank you again, all of you, this is my first VoIP experience and I would really like to get it right on the first attempt.

Tom.

[Jason Learmouth]

From the admin guide:

Enter a Type of Service (TOS) value or a DiffServ value, whichever your network
currently supports. This byte is applied to media originating from all ShoreGear
physical switches (SoftSwitches excluded) and IP phones, including voice calls,
voicemail, workgroup, account code collection (ACC), and contact center calls. The
value entered in this field must be a decimal number between 0 to 255.

In 9.x the ToS support was enhanced as follows:

ShoreTel 9 extends the DiffServ/ToS setting to all voicemail, workgroup, account code collection (ACC), or contact center calls. One setting applies to all ShoreTel servers in a ShoreTel system.
ShoreTel 9 also introduces DiffServ/ToS marking for video IP packets. The default value for the Video DiffServ/ToS Byte is 0, indicating that priority is not defined for Video packets. Changing the Video QoS setting does not affect video sessions in progress. The updated value is applied to new video sessions. Call Manager recognizes the change without being restarted.

You don't want to prioritise the traffic to PCM, voicemail playback will still be tagged as voice. I don't think you need to worry about whether ShoreTel can mark it's packets correctly or not, your effort should be put into configuring your network to treat all these correctly tagged packets appropriately. Things get tricky when you need to start configuring devices indendently instead of with a single tick box like in ShoreTel...

[cburgy]

You will absolutely want to do QOS on the LAN level. It is a best practice (VLANs enough won't just gaurantee voice quality) and, on most switches now, it is really easy to enable. The vast majority of switches already have a DSCP value mapped for EF to the appropriate hardware queue.

You should definitely route between the two sites as discussed. A Juniper SRX210 will be more than adequate for that link.

Prioritizing non-voice traffic to PCM is something you should be aware of. In a small two site envrionment with the amount of bandwidth you have, it will probably be a very rare issue.

In larger distributed environments, delay for PCM because of congestion over the MPLS network is a very real challenge. We've seen a ton of environments where users get extremely frustrated that their PCM is extremely delayed for call control purposes.

If you do opt to implement QOS for non-voice applications from Director, pay very close attention to how you write your ACLs to mark traffic. You'll want to honor and ignore EF marked packets. You should write the rule to prioritize in AF1-4 ranges based upon other critical applications in your network envrionment and how you need to prioritize them.

[eazeaz]

PCM Traffic QOS

We prioritize our PCM traffic... and have found it to be a must in many situations. When starved, the PCM can act "crazy".

We have several levels of QOS

VOICE
PCM TRAFFIC
STANDARD DATA
EVERYTHING ELSE
LOW PRIORITY

We actually de-prioritize a set of traffic to make it take bandwidth only when nothing else is needing bandwidth - replication, SMTP traffic, print jobs, etc.