asterisk users - Feb 2006 - OT: VoIP over bonded link

I have to provision several dozen * users to a seperate building on our
campus in the same subnet. Ordinarily, I'd just run a gigabit cat6 cable to
another switch if it doesn't violate the 100 metre rule, but this building
is several hundred metres away from my backbone. My only option for cabling
to the remote building is copper. My plan is to provision them with a Linux
bridge with 4 NIC's: 1 gigabit to the backbone, and three bonded together as
a single interface (90 mbit aggregate), then plugged into this dealie:

http://www.blackbox.com/Catalog/Detail.aspx?cid=425,1423,1424&mid=4946

At the remote building, the reverse: another Linux box with 4 NIC's that
de-aggregates the link to a gigabit connection on a switch, and then to the
wall plates. I'm pretty sure this will work for data no problem, but I'm
a
little concerned about latency on a timing-sensitive applicaiton like VoIP. 

Anyone have experience with VoIP over bonded link? Is there a gotcha? Is
this a stupid idea? On my whiteboard it looks fine!

On Thursday 23 Feb 2006 17:30, Colin Anderson wrote:
> I have to provision several dozen * users to a seperate building on our
> campus in the same subnet. Ordinarily, I'd just run a gigabit cat6
cable to
> another switch if it doesn't violate the 100 metre rule, but this
building
> is several hundred metres away from my backbone. My only option for cabling
> to the remote building is copper. My plan is to provision them with a Linux
> bridge with 4 NIC's: 1 gigabit to the backbone, and three bonded
together
> as a single interface (90 mbit aggregate), then plugged into this dealie:
>
> http://www.blackbox.com/Catalog/Detail.aspx?cid=425,1423,1424&mid=4946
>
> At the remote building, the reverse: another Linux box with 4 NIC's
that
> de-aggregates the link to a gigabit connection on a switch, and then to the
> wall plates. I'm pretty sure this will work for data no problem, but
I'm a
> little concerned about latency on a timing-sensitive applicaiton like VoIP.
>
> Anyone have experience with VoIP over bonded link? Is there a gotcha? Is
> this a stupid idea? On my whiteboard it looks fine!
It's stupid. Don't ever connect 2 different building with copper.
Just wait until you get some kind of lightening hit or electrical
fault, but make sure you are no where near it. Use fibre.


B

-- 
http://www.mailtrap.org.uk/

> I have to provision several dozen * users to a seperate building on our
> campus in the same subnet. Ordinarily, I'd just run a gigabit cat6
cable to
> another switch if it doesn't violate the 100 metre rule, but this
building
> is several hundred metres away from my backbone. My only option for cabling
> to the remote building is copper. My plan is to provision them with a Linux
> bridge with 4 NIC's: 1 gigabit to the backbone, and three bonded
together as
> a single interface (90 mbit aggregate), then plugged into this dealie:
> 
> http://www.blackbox.com/Catalog/Detail.aspx?cid=425,1423,1424&mid=4946
> 
> At the remote building, the reverse: another Linux box with 4 NIC's
that
> de-aggregates the link to a gigabit connection on a switch, and then to the
> wall plates. I'm pretty sure this will work for data no problem, but
I'm a
> little concerned about latency on a timing-sensitive applicaiton like VoIP.
> 
> Anyone have experience with VoIP over bonded link? Is there a gotcha? Is
> this a stupid idea? On my whiteboard it looks fine! 
Some thoughts that you might want to consider...

The vdsl box runs at speeds "up to 15 meg". That translates into the
longer
the copper loop, the slower the speed. You'll probably want to accurately
measure the copper loop length and translate that into some 'expected'
speed.
Probably won't be 15 meg, and whatever the documentation suggests, it
will likely be a fair amount slower then that.

Does the vdsl truly operate in a full duplex mode with equal bandwidth
in either direction?

We've worked with many corporations and institutions in over 40 states
doing network performance assessments, and seldom (if ever) do bonded
interfaces actually work the way that you might think they work. I've not
spent any time with the linux bonding that you're considering, but you
might want to better understand exactly how that works. E.g., some bonding
actually functions at 'per packet' level, which implies the maximum
speed
of any single packet is the speed of one vdsl circuit. 

If one of the bonded circuits has errors, what impact does it have on the
other three error-free circuits. (Its not uncommon for one interface to
have very significant impact on all other interfaces.)

If all of the above can be answered with positive thoughts, you'll still
want to consider some form of QoS on those links to ensure the voip
packets are not held in a queue.

>It's stupid. Don't ever connect 2 different building with copper.
>Just wait until you get some kind of lightening hit or electrical
>fault, but make sure you are no where near it. Use fibre.

Thanks for the reply. Unfortunately, the conduit for the provisioning of the
new building is unsuitable for fibre (too many sharp bends) and we can't
core out the concrete and put in a new conduit because of obstacles in the
way that make laying new conduit impractical, so we are stuck with
(existing) copper. We already have copper-to-copper connections of different
types (electrical, security etc) between the buildings so a lightning strike
is going to hose us no matter what. 

That aside, does anyone have opinions on my original question as to the
suitability of bonded links for VoIP?

>Some thoughts that you might want to consider...
>The vdsl box runs at speeds "up to 15 meg". That translates into
the longer
>the copper loop, the slower the speed. You'll probably want to
accurately
>measure the copper loop length and translate that into some
'expected'
speed.
>Probably won't be 15 meg, and whatever the documentation suggests, it
>will likely be a fair amount slower then that.
>Does the vdsl truly operate in a full duplex mode with equal bandwidth
>in either direction?
>We've worked with many corporations and institutions in over 40 states
>doing network performance assessments, and seldom (if ever) do bonded
>interfaces actually work the way that you might think they work. I've
not
>spent any time with the linux bonding that you're considering, but you
>might want to better understand exactly how that works. E.g., some bonding
>actually functions at 'per packet' level, which implies the maximum
speed
>of any single packet is the speed of one vdsl circuit. 
>If one of the bonded circuits has errors, what impact does it have on the
>other three error-free circuits. (Its not uncommon for one interface to
>have very significant impact on all other interfaces.)
>If all of the above can be answered with positive thoughts, you'll still
>want to consider some form of QoS on those links to ensure the voip
>packets are not held in a queue.
Good suggestions, thanks. I'm going to build a prototype and do some
analysis. If it's good, I'll post to the list.

Colin Anderson wrote:
> I have to provision several dozen * users to a seperate building on our
> campus in the same subnet. Ordinarily, I'd just run a gigabit cat6
cable to
> another switch if it doesn't violate the 100 metre rule, but this
building
> is several hundred metres away from my backbone. My only option for cabling
> to the remote building is copper. My plan is to provision them with a Linux
> bridge with 4 NIC's: 1 gigabit to the backbone, and three bonded
together as
> a single interface (90 mbit aggregate), then plugged into this dealie:
>
> http://www.blackbox.com/Catalog/Detail.aspx?cid=425,1423,1424&mid=4946
>
> At the remote building, the reverse: another Linux box with 4 NIC's
that
> de-aggregates the link to a gigabit connection on a switch, and then to the
> wall plates. I'm pretty sure this will work for data no problem, but
I'm a
> little concerned about latency on a timing-sensitive applicaiton like VoIP.
>
> Anyone have experience with VoIP over bonded link? Is there a gotcha? Is
> this a stupid idea? On my whiteboard it looks fine!
If you have line of site, or even close, you can consider running VoIP 
over wireless bridges.  We've run VoIP and network traffic over the 
Cisco 1300 and 1400 series bridges with no problems.  They will support 
voice VLANs and qos. 

Thanks,
Nick