[cisco-voip] 8945 not taking changes on 9.1.1a
Stephen Welsh
stephen.welsh at unifiedfx.com
Fri Oct 18 16:51:17 EDT 2013
Maybe I missed something in the current dialog, but is this not the ARP table limitation on CUCM?
If you are only having issues with phones on the same VLAN/Subnet that would be my guess ;)
Stephen
On 18 Oct 2013, at 19:39, Erick B. <erickbee at gmail.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<tel:314-212-1814>
PS Engineering: Innovate & Ignite.
From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<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<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto: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/3c9777c4/attachment.html>
More information about the cisco-voip
mailing list