[cisco-voip] 8945 not taking changes on 9.1.1a

Erick Wellnitz ewellnitzvoip at gmail.com
Fri Oct 18 15:22:46 EDT 2013 

To clarify, that shold be done on all nodes.


On Fri, Oct 18, 2013 at 2:21 PM, Erick Wellnitz <ewellnitzvoip at gmail.com>wrote:

> Oops. I need to read the entire output.  :)
>
> I remember an issue like this back in the 6.1.2 days.  DB Replication
> would show normal but the CCM process would be missing when doing a show
> tech notify I think it was.   ANother time I had an issue where entries
> were not actually deleting from the database.
>
> After you delete the phone: run sql select * from device where name =
> 'SEP<macaddress>'
>
>
> It shouldn't return any results.
>
>
>
> On Fri, Oct 18, 2013 at 2:10 PM, Brian Meade (brmeade) <brmeade at cisco.com>wrote:
>
>>  Both are in a start of 2 here.  3 is just one of the node IDs.****
>>
>> ** **
>>
>> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On
>> Behalf Of *Erick Wellnitz
>> *Sent:* Friday, October 18, 2013 3:07 PM
>> *To:* Erick B.
>> *Cc:* voip puck
>> *Subject:* Re: [cisco-voip] 8945 not taking changes on 9.1.1a****
>>
>> ** **
>>
>> They should both be 2.****
>>
>>  ****
>>
>> Status 3 means your tables are suspect on that node.****
>>
>>  ****
>>
>> https://supportforums.cisco.com/docs/DOC-13672****
>>
>> ** **
>>
>> On Fri, Oct 18, 2013 at 1:39 PM, Erick B. <erickbee at gmail.com> wrote:****
>>
>> Just changing the extension on the phone. It also won't reset from CUCM.
>>  Found out this just effects local phones on same 3750 as the UCS server
>> (same VLAN). All phones - not just 8945. One 8945 at a remote site we can
>> change just fine and reset just fine. The 3750 looks fine, normal port
>> configurations. ****
>>
>> ** **
>>
>> All services are started, the cluster was rebooted 2 days ago. No change.
>> No errors in RTMT and the phone console log shows it downloading the trust
>> file and configuration file fine. Phone console log says it authenticates
>> the configuration file fine. TFTP Service set to Build All CNF and
>> restarted, no change. ****
>>
>> ** **
>>
>> In the 'utils dbreplication runtimestate' below, RPC value on subscriber
>> is 3 - is that a problem?****
>>
>> ** **
>>
>> ** **
>>
>> utils dbreplication status****
>>
>> ** **
>>
>> admin:file view activelog
>> cm/trace/dbl/sdi/ReplicationStatus.2013_10_18_13_07_27.out****
>>
>> ** **
>>
>> Fri Oct 18 13:07:27 2013 main()  DEBUG:  -->****
>>
>> Fri Oct 18 13:07:30 2013 main()  DEBUG:  Replication cluster summary:****
>>
>> SERVER                 ID STATE    STATUS     QUEUE  CONNECTION CHANGED**
>> **
>>
>> -----------------------------------------------------------------------**
>> **
>>
>> g_ccm1_ccm9_1_1_20000_5    2 Active   Local           0****
>>
>> g_ccm2_ccm9_1_1_20000_5    3 Active   Connected       0 Oct 16 17:17:05**
>> **
>>
>> Fri Oct 18 13:07:31 2013 main()  DEBUG:  <--****
>>
>> ** **
>>
>> end of the file reached****
>>
>> ** **
>>
>> admin:file view activelog
>> cm/trace/dbl/sdi/ReplicationStatus.2013_10_18_13_07_19.out****
>>
>> ** **
>>
>> Fri Oct 18 13:07:19 2013 main()  DEBUG:  -->****
>>
>> Fri Oct 18 13:07:22 2013 main()  DEBUG:  Replication cluster summary:****
>>
>> SERVER                 ID STATE    STATUS     QUEUE  CONNECTION CHANGED**
>> **
>>
>> -----------------------------------------------------------------------**
>> **
>>
>> g_ccm1_ccm9_1_1_20000_5    2 Active   Connected       0 Oct 16 17:17:04**
>> **
>>
>> g_ccm2_ccm9_1_1_20000_5    3 Active   Local           0****
>>
>> Fri Oct 18 13:07:24 2013 main()  DEBUG:  <--****
>>
>> ** **
>>
>> end of the file reached****
>>
>> ** **
>>
>> ** **
>>
>> admin:utils dbreplication runtimestate****
>>
>> ** **
>>
>> DB and Replication Services: ALL RUNNING****
>>
>> ** **
>>
>> DB CLI Status: No other dbreplication CLI is running...****
>>
>> ** **
>>
>> Cluster Replication State: BROADCAST SYNC Completed on 1 servers at:
>> 2013-08-30-13-38****
>>
>>      Last Sync Result: SYNC COMPLETED  603 tables sync'ed out of 603****
>>
>>      Sync Errors: NO ERRORS****
>>
>> ** **
>>
>> DB Version: ccm9_1_1_20000_5****
>>
>> Repltimeout set to: 300s****
>>
>> PROCESS option set to: 1****
>>
>> ** **
>>
>> Cluster Detailed View from CCM1 (2 Servers):****
>>
>> ** **
>>
>>                                 PING            CDR Server      REPL.
>> DBver& REPL.    REPLICATION SETUP****
>>
>> SERVER-NAME     IP ADDRESS      (msec)  RPC?    (ID) & STATUS   QUEUE
>> TABLES LOOP?    (RTMT) & details****
>>
>> -----------     ------------    ------  ----    --------------  -----
>> ------------    -----------------****
>>
>> CCM1     10.1.1.10    0.046   Yes     (2)  Connected   0      match   Yes
>>    (2) PUB Setup Completed****
>>
>> CCM2     10.1.1.11    0.382   Yes     (3)  Connected   0      match   Yes
>>    (2) Setup Completed****
>>
>> ** **
>>
>> admin:utils dbreplication runtimestate****
>>
>> ** **
>>
>> DB and Replication Services: ALL RUNNING****
>>
>> ** **
>>
>> Cluster Replication State: Only available on the PUB****
>>
>> ** **
>>
>> DB Version: ccm9_1_1_20000_5****
>>
>> Repltimeout set to: 300s****
>>
>> PROCESS option set to: 1****
>>
>> ** **
>>
>> Cluster Detailed View from CCM2 (2 Servers):****
>>
>> ** **
>>
>>                                 PING            CDR Server      REPL.
>> DBver& REPL.    REPLICATION SETUP****
>>
>> SERVER-NAME     IP ADDRESS      (msec)  RPC?    (ID) & STATUS   QUEUE
>> TABLES LOOP?    (RTMT)****
>>
>> -----------     ------------    ------  ----    --------------  -----
>> ------------    -----------------****
>>
>> CCM1     10.1.1.10    0.458   Yes     (2)  Connected   0      match   Yes
>>    (2)****
>>
>> CCM2     10.1.1.11    0.050   Yes     (3)  Connected   0      match   Yes
>>    (2)****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> On Fri, Oct 18, 2013 at 1:26 PM, Ryan Ratliff (rratliff) <
>> rratliff at cisco.com> wrote:****
>>
>> What changes are you making that aren't taking? The phone registering
>> after being deleted from the db is a cucm issue, not a phone one.****
>>
>> ** **
>>
>> Try a db replication status check from the cli.
>>
>> Sent from my iPhone****
>>
>>
>> On Oct 18, 2013, at 1:58 PM, "Erick B." <erickbee at gmail.com> wrote:****
>>
>>  The console logs on the phone also show it successfully downloading the
>> SEPxxxx cnf xml file and successfully authenticating it.  Not seeing any
>> errors in the console log. ****
>>
>> ** **
>>
>> On Fri, Oct 18, 2013 at 11:54 AM, Erick B. <erickbee at gmail.com> wrote:***
>> *
>>
>> Yes. Factory defaulted phone also. ****
>>
>> ** **
>>
>> Other phone models take changes fine and stop working when they are
>> deleted from CUCM. ****
>>
>> Servers have been rebooted to. ****
>>
>> ** **
>>
>> The phone took the firmware update fine, and the phone web page (status
>> message, debug display) show it downloading trust files fine and config sgn
>> file (HTTP) fine. No errors there about timeout downloading config files,
>> etc. ****
>>
>> ** **
>>
>> ** **
>>
>> On Fri, Oct 18, 2013 at 11:38 AM, Heim, Dennis <Dennis.Heim at wwt.com>
>> wrote:****
>>
>> Have you tried clearing the security settings?****
>>
>>  ****
>>
>> *Dennis Heim | Solution Architect (Collaboration)*****
>>
>> World Wide Technology, Inc. | 314-212-1814****
>>
>>  ****
>>
>> *PS Engineering: ** Innovate & Ignite.*****
>>
>> * *****
>>
>>  ****
>>
>> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On
>> Behalf Of *Erick B.
>> *Sent:* Friday, October 18, 2013 12:26 PM
>> *To:* voip puck
>> *Subject:* [cisco-voip] 8945 not taking changes on 9.1.1a****
>>
>>  ****
>>
>> Weird one here, anyone seen this before?****
>>
>>  ****
>>
>> Have a few 8945s that aren't taking changes. ****
>>
>>  ****
>>
>> DB replication shows 2 on all servers. ****
>>
>>  ****
>>
>> Weird thing is, if we delete the 8945 from CUCM the 8945 still registers
>> and works with old extension and 8945 phone web page shows it is registered
>> to the right call manager server and the phone can make calls with the
>> phone not being in CUCM. ****
>>
>>  ****
>>
>> Have updated a few to current firmware version, same thing. ****
>>
>> ** **
>>
>> ** **
>>
>>   _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip****
>>
>>  ** **
>>
>>
>> _______________________________________________
>> 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/20131018/d56f1663/attachment.html>

More information about the cisco-voip mailing list