[cisco-voip] Callmanager CFWDAll

[Lelio Fulgenzi]

we had this problem and all our servers are withing spitting distance of each other but in seperate data centres.

ok, maybe not spitting distance, but unless there's a fog rolling in you can see the buildings from each other.

--------------------------------------------------------------------------------
Lelio Fulgenzi, B.A.
Network Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
Sanity First : Number of days with fewer than
50 messages in my inbox at the end of the day:         14
  ----- Original Message ----- 
  From: Ed Leatherman 
  To: Wes Sisk 
  Cc: cisco-voip at puck-nether.net Voip 
  Sent: Friday, April 07, 2006 9:46 AM
  Subject: Re: [cisco-voip] Callmanager CFWDAll


  We do have a similar configuration as far as distance is concerned, 2 of the subs are not local. Near as I can tell though the problem yesterday was cluster wide, or at least it was occuring both at the "remote" site and also affecting phones registered to subs sitting right beside the publisher. We were seeing #3 I guess, there were no error messages on the phones. Not using any third party apps on the servers other than AV. 

  Some users were complaining that they could not set forwarding at all (i experienced this on my desk phone as well). Others were able to but the animated forwarding icon would not go away.


  On 4/7/06, Wes Sisk <wsisk at cisco.com> wrote:
    Ed,

    we have seen a strong correlation between CFA failures and CM servers separated by some distance of network rather than CM's being connected to immediately adjacent switches.

    there are 3 primary steps to setting CFA:
    1. phone tells primary CM it wants to set CFA
    2. primary CM tells publisher to set CFA
    3. publisher tells all CMs in the cluster CFA has been set.

    if 2 fails you get a database error on the ipphone
    if 3 fails you set CFA and receive no error but phone does not fwd.

    #2 is performed through DCOM - DBLHelper does not test this.  dtcping and rpcping from microsoft can test DCOM RPC's but that's about it.  Being RPC based the communication uses multiple random ephemereal ports and connects are established dynamically.
    #3 is performed through a TCP session from aupair.exe on a random port on the publisher to ccm.exe on port TCP:7727 of some random server in the cluster.  Usually when we see CFA failures we find out the random server is remote from the rest of the servers in the cluster.  Note if aupair.exe does not detect any change notifications pending it may not establish this session to port 7727. I have seen this problem only once when someone used a 3rd party (not MS or Cisco) database management app on the SQL instance running on the CM publisher and it removed all triggers from the CCM database.

    /Wes

    Ed Leatherman wrote: 
    Anyone having problems with CFWDAll not working every now and then? I've been having trouble with it ever since we upgraded to 4.0.. albeit they are getting less frequent as I apply various SR's. We just had a burp this morning with it and I had to reload DBL Mon this morning to fix it.. was relatively painless but kinda annoying to still be having these problems. So wondering if anyone else is having it happen. We're running 4.1(3)SR3a now.

    -- 
    Ed Leatherman
    IP Telephony Coordinator
    West Virginia University
    Telecommunications and Network Operations 
----------------------------------------------------------------------------
_______________________________________________cisco-voip mailing listcisco-voip at puck.nether.net 
    https://puck.nether.net/mailman/listinfo/cisco-voip 



  -- 
  Ed Leatherman
  IP Telephony Coordinator
  West Virginia University
  Telecommunications and Network Operations 


------------------------------------------------------------------------------


  _______________________________________________
  cisco-voip mailing list
  cisco-voip at puck.nether.net
  https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20060407/cc893733/attachment.html