Sandy,

Please take note of the wording before jumping the gun.  Teamed NICs seem to
work by my account as well, but Ipswitch specifically refused to support the
previous issue we had with peering due to the teamed network configuration (if
you'll recall I had asked you about this odd problem with the multihomed
configuration last year).  Anyhow, Ipswitch insisted on having us remove the
teaming configuration before continuing with support.

Chris, take it for what it's worth.  Peering works well.  Based on Sandy and
Len's comments combined, it might help people make recommendations if you
provide more information about your anticipated configuration (from an email
architecture standpoint as well as network).

When we migrated several servers to a newer consolidated system, we chose to
use peering to allow the mail systems to co-exist as we made the transition.
This was required because 140 remote sites all relied on the servers and were
being upgraded & configured site by site.  We found that once more than 1/2 of
the accounts had been migrated to the new servers, we noticed that we were
seeing a lot of duplication in emails & active SMTP delivery threads since
messages were being duplicated roughly half of the time.  This is compounded
if your IMail servers forward all email through anti-virus / spam gateways (as
the email could potentially hit the gateway twice), so the gateway servers may
see some increased traffic as well.  If you double your daily traffic and it
is still well under capacity for a single server then this is most likely not
a concern for individual server resources.

Peering will reduce the burden on a server for IMAP/POP/auth requests, but may
not necessarily reduce overall SMTP traffic unless using a hub & spoke / smart
bridgehead type configuration which is intelligent enough to route emails to
the correct server.  This is less of an issue if all servers are on the same
LAN.  Over a WAN however, this could be an issue.  This is of course entirely
dependant on the amount of traffic you anticipate, and the layout of your
networks.

Regards,

Ives


----- Original Message ----- 
From: "Sanford Whiteman" <[EMAIL PROTECTED]>
To: "Ives Stoddard" <[EMAIL PROTECTED]>
Sent: Wednesday, June 18, 2003 10:59 PM
Subject: Re[2]: [IMail Forum] Peering


> >  1)  Ipswitch  will  not  support  NIC  teaming,  particularly  with
> > Peering...
>
> Strange,  I've  never  had  a  prob  with this (3com and Intel teaming
> drivers).
>
> > Keep  in  mind  that  as you add the number of nodes, you add to the
> > likelihood  that  a server will have to lookup and forward the email
> > to  another server. This can add traffic to your network...
>
> I  really  think  very  few  people  can saturate a LAN link with mail
> traffic,  since disk I/O and CPU will bottleneck much more quickly. If
> a  network  is  already  taxed,  it's  feasible,  but LAN bandwidth is
> relatively  cheap these days (then again, I've been able to team where
> you  haven't, thus doubling/tripling bandwidth at will). Vis-a-vis CPU
> utilization  due directly to network traffic, since a peering setup is
> designed to distribute disk, network, and CPU across multiple servers,
> overall  host  resource  consumption  should  go  down as you add more
> servers (even if ratios shift to more network resources being used).
>
> If  WAN  connections  are  being  used,  one does have to be much more
> careful  and  truly  model  traffic  to  determine  how  much  will be
> intra-peer, how much will be inter-peer, how much remote delivery from
> a peer to the outside.
>
> Also on the high end, if your network latency and number of peers keep
> SMTP  delivery processes open for prolonged periods of time, you could
> starve the local machine if it's also trying to perform local delivery
> and  message  retrieval.  This  is why I recommend using asymmetric or
> "bridgehead"  peers  that  have  no  local  userbase, thus eliminating
> resource contention with mailbox server tasks.
>
> -Sandy
>
>
> ------------------------------------
> Sanford Whiteman, Chief Technologist
> Broadleaf Systems, a division of
> Cypress Integrated Systems, Inc.
> e-mail: [EMAIL PROTECTED]
> ------------------------------------
>
>
> To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
> List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
> Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
>


To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/

Reply via email to