Sorry Ryan, I assumed that was a problem with replication (which in turn could be caused by a connectivity problem). I should have reviewed my information before posting. I'm seeing kDbConnection Failed errors from the DBLM service on the publisher node around the time we see saw the problem this morning, was making me think database replication problem.
<br><br>I just wish I could find some indication of what the problem is, some of the subscriber nodes are on the same switch/VLAN as the pub, and they are seeing the problem also when it occurs.. but I dont see anything to indicated those interfaces went down or otherwise had problems. Perhaps something on the pub is breaking it... bout the only other thing I have running there is CSA and antivirus.
<br><br><br><br><div><span class="gmail_quote">On 4/3/07, <b class="gmail_sendername">Ryan Ratliff</b> <<a href="mailto:rratliff@cisco.com">rratliff@cisco.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
/rant on<br>The ONLY time database replication will cause an issue is when your<br>publisher goes away and subs start using their local database.<br><br>AT NO OTHER POINT will it cause issues. This is especially true for
<br>CFA failures, since if your pub is down CFA is not going to work anyhow.<br><br>You may have connectivity issues where DB replication failure is a<br>symptom, but it is just that, a symptom (and a pretty minor one at<br>
that). If your subs cannot connect to the pub you've got much bigger<br>issues than replication. DBLHelper is nice and all, but all it shows<br>you is if your SQL jobs are running (on the replication tab anyway).<br>
<br>I swear a part of my inner troubleshooter dies a little bit every<br>time I see somebody bust out DBLHelper as the first step in<br>troubleshooting a completely unrelated problem. "My MOH is broken,<br>but DBLHelper says everything is fine!"... "I put this firewall
<br>between my CMs and now I can't make any calls between those servers,<br>but DBLHelper is all smileys!"<br><br>/rant off<br><br>If you go searching the archives for this list I've sent several<br>emails in the past on how to troubleshoot CFA failures in
4.x. There<br>were some pretty big architectural changes that have exposed some<br>issues with change notification. Thankfully they go away in 5.x.<br><br><br>-Ryan<br><br>On Apr 3, 2007, at 9:50 AM, Lelio Fulgenzi wrote:
<br><br>I'm convinced that it has to do with the replication of databases and<br>nothing to do with CallManager version.<br><br>Even the dblhelper tool can't illustrate with any confidence that<br>your databases are in sync. It might work to show you that they are
<br>out of sync, but if you see all smiley faces, don't trust your cat's<br>life on it.<br><br><br>------------------------------------------------------------------------<br>--------<br>Lelio Fulgenzi, B.A.<br>Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
<br>(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)<br>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>...there's no such thing as a bad timbit...<br>----- Original Message -----<br>From: Ed Leatherman
<br>To: ciscovoip<br>Sent: Tuesday, April 03, 2007 9:46 AM<br>Subject: [cisco-voip] Callforward all keeps getting stuck<br><br>Hello,<br><br>We've had an ongoing problem with the callforward all feature on the<br>phones ever since we went from ccm
3.x for 4.x. usually it would only<br>happen maybe once every couple months... while still very annoying we<br>could live with it. I've probably opened 4 different TAC SR's on it,<br>with little success in actually fixing it.
<br><br>Basically we have people who forward their lines to another number or<br>to voicemail, and then they cannot remove the forwarding, nor can we<br>do it from CCMadmin.<br><br>For some reason the past week i've had it happen almost everyday. The
<br>work around is very easy, just restarting the DBL monitor service on<br>all the nodes in the cluster fixes the problem. But its still an<br>interuption of service for alot of departments. I'm going to open yet<br>
another TAC case on it.. but does anyone have any suggestions on a<br>possible cause? I don't believe we're having a networking problem but<br>i'm open to suggestions. Currently running ccm 4.1.3sr4d.<br><br>--
<br>Ed Leatherman<br>Senior Voice Engineer<br>West Virginia University<br>Telecommunications and Network Operations<br><br><br>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net">
cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>_______________________________________________<br>cisco-voip mailing list
<br><a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></blockquote></div>
<br><br clear="all"><br>-- <br>Ed Leatherman<br>Senior Voice Engineer<br>West Virginia University<br>Telecommunications and Network Operations