<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>Re: [cisco-voip] Clustering over WAN - Design question</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>What is your bandwith beetwen sites?, maybe the best solution is change the infraestructure<BR>
<BR>
<BR>
<BR>
Victor Manuel Rodriguez Gutierrez<BR>
Neoris Consulting Services<BR>
Tel. +52 81 88885182<BR>
San Pedro Garza Garcia<BR>
<BR>
<BR>
----- Mensaje original -----<BR>
De: cisco-voip-bounces@puck.nether.net &lt;cisco-voip-bounces@puck.nether.net&gt;<BR>
Para: Phil G &lt;pgciscovoip@gmx.net&gt;<BR>
CC: cisco-voip@puck.nether.net &lt;cisco-voip@puck.nether.net&gt;<BR>
Enviado: Fri Oct 02 19:27:45 2009<BR>
Asunto: Re: [cisco-voip] Clustering over WAN - Design question<BR>
<BR>
<BR>
It sounds to me like your problem is the frequent WAN failure more so than the lack of a subscriber at the remote location.&nbsp;&nbsp; How is it acceptable for the data network to be down so often?<BR>
<BR>
Can you resolve that or build in redundancy with an equal cost, possibly diverse path?<BR>
<BR>
<BR>
<BR>
On Fri, Oct 2, 2009 at 10:07 AM, Phil G &lt;pgciscovoip@gmx.net&gt; wrote:<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; That means, if i have the following environment:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SITE A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SITE B<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pub&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sub2<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -------&nbsp; WAN&nbsp; ------<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sub1<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pub, Sub1 and Sub2 are all running ccm.exe, ICCS-real-time traffic would be 1,5 Mbps from Sub2 to Pub plus 1,5 Mbps from Sub2 to Sub1. Plus additional 1,5 Mbps ICCS database traffic from Sub2 to Pub. That means 4,5 Mbps over WAN. Correct?<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If i add another SITE C with a Sub3, then there would be an additional 1,5 Mbps between SITE C and SITE B plus the existing 4,5 Mbps between SITE A and B and another 4,5 Mbps between SITE A and SITE C?<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Another question: Do you have any experience how good the database replication will start again after a WAN-failure. Problem is that we have a remote site with SRST. Now there are frequently WAN-link-failures and the people are complaining about the feature-set in SRST. The idea is now, that we place a subscriber-server at this site and raise the bandwidth. Now with the given reliability of the WAN-link, i am fearing about other &quot;symptoms&quot; we will facing when the link is up again (broken replications or something like that). But also when there are other issues on the link like more packet loss.<BR>
<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Wes Sisk wrote:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Correct, it is per server.&nbsp; It is not &quot;per site&quot;.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; On Friday, October 02, 2009 4:03:53 AM, Phil G &lt;pgciscovoip@gmx.net&gt; wrote:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hi!<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I have read the SRND-section of clustering over WAN and i have a question about bandwidth requirements: SRND states, that you need 1,544 Mbps minimum for sites that are clustered over WAN for ICCS real-time traffic. It says &quot;sites&quot; not &quot;servers&quot;.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; And you need additional 1,544 Mbps for every subsriber server remote to the publisher for database traffic. Here is says &quot;server&quot; not &quot;sites&quot;.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Why is the real-time traffic independant of the number of servers at a site? I thought, the real-time traffic is fully meshed between each server running ccm.exe, so if i have 2 remote subscibers at a site, i would assume that i would have 1,544 Mbps to every other server running ccm.exe. So in a 2 site environment with 2 subsriber at each site i would have 4 ICCS-real-time-traffic flows, each with 1,544 Mbps. Is that correct?<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _______________________________________________<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cisco-voip mailing list<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cisco-voip@puck.nether.net<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _______________________________________________<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cisco-voip mailing list<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cisco-voip@puck.nether.net<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
<BR>
</FONT>
</P>


<HR>
<FONT size=2><FONT color=#ff0000>
<P class=MsoNormal 
style="MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><FONT 
color=#000000><FONT size=1><SPAN 
style="FONT-SIZE: 7pt; FONT-FAMILY: 'Trebuchet MS'; mso-bidi-font-family: 'Trebuchet MS'; mso-ansi-language: EN-US"><FONT 
face=Arial size=1><FONT face=Verdana><STRONG>Este documento puede incluir 
información confidencial y propiedad de Neoris y deberá ser leído solamente por 
la o las personas a quienes está dirigido. Si usted ha recibido este mensaje por 
error, por favor avise inmediatamente al remitente contestando y eliminando este 
correo. Cualquier punto de vista u opiniones expresadas en este mensaje son del 
remitente y no necesariamente coinciden con aquellas de Neoris. Este documento 
no deberá ser reproducido, copiado, distribuido, publicado, ni modificado por 
terceros sin la autorización por escrito de Neoris.</STRONG><FONT size=2> 
</FONT></P>
<P><FONT color=#ff0000 size=1><STRONG>Este mensaje ha sido&nbsp;<SPAN 
class=254115416-27052005>verificado </SPAN>contra virus. Visítenos en 
</STRONG></FONT><A title=outbind://91/www.neoris.com 
href="outbind://91/www.neoris.com"><U title=outbind://91/www.neoris.com><FONT 
title=outbind://91/www.neoris.com size=1><EM 
title=outbind://91/www.neoris.com><STRONG>www.neoris.com</STRONG></EM></FONT></U></A>.</P></FONT></FONT></SPAN></FONT></FONT>
<P class=MsoNormal 
style="MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"><FONT 
color=#000000><FONT size=1><STRONG><SPAN 
style="FONT-SIZE: 7pt; FONT-FAMILY: 'Trebuchet MS'; mso-bidi-font-family: 'Trebuchet MS'; mso-ansi-language: EN-US"><FONT 
face=Arial size=1><FONT face=Verdana>This document may include proprietary and 
confidential information of Neoris, and may only be read by those person or 
persons to whom it is addressed. If you have received this e-mail message in 
error, please advise the sender immediately by reply e-mail and delete this 
message. Any views or opinions expressed in this e-mail&nbsp; are those of the 
sender and do not necessarily coincide with those of Neoris. This document may 
not be reproduced, copied, distributed, published, modified or furnished to 
third parties, without the prior written consent of Neoris.</FONT></P>
<P><FONT face=Verdana color=#ff0000 size=1><STRONG>This e-mail message has been 
scanned for viruses and cleared. Visit us at </STRONG></FONT><FONT face=Verdana 
size=1><STRONG><EM><A 
href="http://www.neoris.com">www.neoris.com</A>.</EM></STRONG></FONT></FONT></SPAN></STRONG></FONT></FONT></FONT></FONT> 

<HR>

<P></P>
</BODY>
</HTML>