asterisk users - Dec 2005 - Bonded ethernet ports and *

Hey all - I'm sure this has been done before, but I'm curious about how
well
it works.. Typically we have all our servers setup for dual fast/gig
ethernet failover... I.e. bond0 slaves eth0 and eth1 and fails over between
the two. This together with dual p/s and raid1'd(at least) drives provides
for a pretty safe solution(aside from building up a second server). So I'm
courious thoughts/expectations/issues with doing network failover...
Probably is a moot point, but I thought I'd ask.


Thanks!!

Rolf Brusletto
Denver, Co.

> Hey all - I'm sure this has been done before, but I'm curious about
how well
> it works.. Typically we have all our servers setup for dual fast/gig
> ethernet failover... I.e. bond0 slaves eth0 and eth1 and fails over between
> the two. This together with dual p/s and raid1'd(at least) drives
provides
> for a pretty safe solution(aside from building up a second server). So
I'm
> courious thoughts/expectations/issues with doing network failover...
> Probably is a moot point, but I thought I'd ask.
I've done profession network assessments for a large number of companies
throughout the US and I've never ever seen bonded nics work as the
implementor expected them to work.

If you think seriously about how well the underlying OS and drivers function,
the length of the code path that must be executed to move packets from the
application layer all the way through to the nic card, you'll find that
most OS's are pressed very hard to keep a 1 gig interface running at max
smoke. Combine that with the overhead of tcp (not udp), latency, and the 
typical tcp windowing, and its even worse.

I'd also be checking exactly how the bonding function works in the 
primary/backup arrangement as several implementations that I've seen do
not handle shared mac addresses very well. That translates into arp table
timeout issues that essentially negates the expected benefits (eg, session
failures).

Could there be some good implementations? Probably, but just haven't seen
any persoanlly as yet.
>From a VoIP perspective, a 100 meg nic interface can (in theory) handle
1,176 simultanous g711 (or about 3,000 g729) conversations. That is 
significantly greater then what can be handled from a processing perspective
(assuming all conversations pass through asterisk code). If all 
conversations essentially involves canreinvite=yes, a 100 meg nic is still
not the bottleneck.

Last, the bonding of two nics at the server level _requires_ the associated
switch interface to support the exact same bonding algorithm. Historically,
that has been a problem for many switch vendors.

Short answer... I'd never do it. Long answer... think in terms of high
availability "systems"; the nic card is the least concerning.

I can say that I've implemented it on several Asterisk servers using the
802.3ad mode and it works very well.  The failover is quick, and there are
none of the issues mentioned here.  I'm not particularly concerned about
running at GigE speeds as the level of traffic in/out of these boxes is
nowhere near that.  YMMV, of course, but in my experience it just works.

- Brad

-----Original Message-----
From: asterisk-users-bounces@lists.digium.com
[mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Rich Adamson
Sent: Tuesday, December 13, 2005 6:14 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] Bonded ethernet ports and *


> Hey all - I'm sure this has been done before, but I'm curious about
> how well it works.. Typically we have all our servers setup for dual 
> fast/gig ethernet failover... I.e. bond0 slaves eth0 and eth1 and 
> fails over between the two. This together with dual p/s and raid1'd(at 
> least) drives provides for a pretty safe solution(aside from building 
> up a second server). So I'm courious thoughts/expectations/issues with 
> doing network failover... Probably is a moot point, but I thought I'd 
> ask.
I've done profession network assessments for a large number of companies
throughout the US and I've never ever seen bonded nics work as the
implementor expected them to work.

If you think seriously about how well the underlying OS and drivers
function, the length of the code path that must be executed to move packets
from the application layer all the way through to the nic card, you'll find
that most OS's are pressed very hard to keep a 1 gig interface running at
max smoke. Combine that with the overhead of tcp (not udp), latency, and the

typical tcp windowing, and its even worse.

I'd also be checking exactly how the bonding function works in the 
primary/backup arrangement as several implementations that I've seen do not
handle shared mac addresses very well. That translates into arp table
timeout issues that essentially negates the expected benefits (eg, session
failures).

Could there be some good implementations? Probably, but just haven't seen
any persoanlly as yet.
>From a VoIP perspective, a 100 meg nic interface can (in theory) handle
1,176 simultanous g711 (or about 3,000 g729) conversations. That is 
significantly greater then what can be handled from a processing perspective
(assuming all conversations pass through asterisk code). If all 
conversations essentially involves canreinvite=yes, a 100 meg nic is still
not the bottleneck.

Last, the bonding of two nics at the server level _requires_ the associated
switch interface to support the exact same bonding algorithm. Historically,
that has been a problem for many switch vendors.

Short answer... I'd never do it. Long answer... think in terms of high
availability "systems"; the nic card is the least concerning.


_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users



The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.