<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
For example sake:<br>
CM1: headquarters<br>
CM2: branch<br>
<br>
When IP connectivity exists between CM1 and CM2 SDL TCP sessions are
established between the 2 ccm processes. Through SDL each server
tells every other server about registered devices. There is
opportunity for duplicate registration and some propagation time so
there is a window of convergence involved. Once things are in sync
each CM node tells every other node about all significant local
state changes. Make sense? This usually helps folks understand why
QoS is so critical on SDL links. SDL links are the vehicle for
synchronization for 2 real time processes. This isn't quite as
sensitive as parallel graphics processing but it's not far off.<br>
<br>
When SDL link goes down each node forgets about all entities it
learned from the remote node. It literally purges them. Devices
have to register to their local node (even the best network admins
miss some especially when it comes to virtual devices like hunt
pilots, route lists, and software media resources). Again there is
opportunity for some duplicate registration. SDL links detect
outage on the order of 10 seconds or less. SCCP devices do
keepalives on the order of 30 seconds with allowance for 1-2 missed
keepalives. 10seconds vs 60-90seconds creates a window of overlap.
If a duplicate registration is detected then CM resets both device
processes. This extends downtime but there really is no way of
knowing which is the "right" registration. This is another window
of convergence.<br>
<br>
So, after convergence the device appears unregistered on the remote
node. For an interesting dig into this scenario take a look at<br>
CSCsc62081 CCM SDL Out of Service / In Service causes Unexpected
Unity Failover.<br>
<br>
and similarly related to realtime synchronization of state machines:<br>
CSCsc62073 Locations Out of Bandwidth causes unexpected Unity
Failover <br>
<br>
It was the same customer who originated both of these. This
customer had truly the worst luck with timing that I have ever seen.<br>
<br>
Regards,<br>
Wes<br>
<br>
<br>
On 4/6/2011 11:51 AM, Ovidiu Popa wrote:
<blockquote
cite="mid:BANLkTimjKJr7LESdFC2B=Yt9A0mXYqm-pA@mail.gmail.com"
type="cite">Hello everyone
<div><br>
</div>
<div>Here's an unusual scenario that kind of puzzles me.</div>
<div><br>
</div>
<div>Here are the details:</div>
<div>- 2 CUCM with Clustering over WAN (HQ and Branch)</div>
<div>- Centralized PSTN Access at HQ (DID numbers routed to HQ)</div>
<div>- 1 phone with the Branch CUCM as primary and the HW CUCM as
secondary</div>
<div><br>
</div>
<div>Disaster strikes, the WAN link goes down and we have a split
brain condition.</div>
<div><br>
</div>
<div>What is the state to the phone on HQ CUCM? Will the phone be
Unregistered or state Unknown?</div>
<div><br>
</div>
<div>And the most important question is will the HQ CUCM follow
the CFUR if the state is Unknown?</div>
<div><br>
</div>
<div>Thanks for your input.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Ovidiu</div>
<div>
<br>
</div>
<div><br>
</div>
<div><br>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
cisco-voip mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</pre>
</blockquote>
</body>
</html>