10-06-2009 12:40 PM - edited 03-15-2019 07:56 PM
I am having an issue trying to register this CUCM module to UCM. First off, we have customer that initially had this on version 4 of Call Manager and they installed a new 7.1.3 cluster and they are trying to register this 6608 T1 module now to version 7.1.3 of UCM.
Note: Registering this as MTP works but when we attempt to register this a gateway we never get registered.
I have an attached trace and can get more info if necessary.
It seems that TFTP is configured properly and CM IP is accurate. Not quite sure what is going on here. I have not ever really worked with these before.
APP Version : M00104000003, DSP Version : M002E031, Built Nov 13 2003 15:00:05
Device Name : MTP0002FCE1A411
00:00:00.000 *** Reset Reason: <DelBugTrap > at timestamp=00:01:33
00:00:00.000 --- DelBugTrap Code <0x502>(GMSG) Timeout, Fail to connect a CCM
00:00:00.000 --- NMP last TCP close cause 0 no record
00:00:00.000 --- DickTracy last TCP close cause 14 Normal close LASTACK
00:00:00.000
(DSP) UBL Status : 0xFF
00:00:00.000 (DSP) Core Status : 0xFF
00:00:00.000 0 ...
00:00:00.000 1 ...
00:00:00.000 2 ...
00:00:00.000 3 ...
00:00:00.000 4 ...
00:00:00.000 5 ...
00:00:00.000 6 ...
00:00:00.000 7 ...
00:00:00.000
00:00:00.070 (XA) MAC Addr : 00-02-FC-E1-A4-11
00:00:00.070 NMPTask:got message from XA Task
00:00:00.070 (NMP) Open TCP Connection ip:7f010501
00:00:00.080 NMPTask:Send Module Slot Info
00:00:00.080 NMPTask:get DIAGCMD
00:00:00.180 NMPTask:get VLANCONFIG 182
00:00:01.350 (CFG) Starting DHCP
00:00:01.350 (CFG) Booting TCP/IP using NMP Info.
00:00:01.350 (CFG) Got 2nd TFTP Server IP = c0a8b60a,0
00:00:01.370 (CFG) CCM TCP/IP Initialized With NMP Info.
00:00:01.370 (CFG) Requesting 0002FCE1A411.cnf.xml File From TFTP Server
00:00:01.380 (CFG) XML Configuration file parsed successfully.
00:00:01.380 (CFG) Configuration completed. Notifying GMSG of NEW_LOADID
00:00:01.380 (GMSG) Config task is completed with boot process or DNS request
00:00:01.380 (GMSG) CM[0] IP = 192.168.182.11
00:00:01.380 (GMSG) CM[1] IP = 192.168.183.12
00:00:01.380 (GMSG) CM[2] IP = 192.168.182.10
00:00:01.380 (GMSG) Start Registration Process..
00:00:01.800 (GMSG) TCP Socket CLOSE: handle=2, cpindex=0, IP=192.168.182.11
00:00:02.300 (GMSG) TCP Socket CLOSE: handle=2, cpindex=1, IP=192.168.183.12
00:00:02.300 (GMSG) TCP Socket CLOSE: handle=2, cpindex=2, IP=192.168.182.10
10-06-2009 01:10 PM
FYI
We have used the 2 links below to enable troubleshooting but to no avail.
10-06-2009 01:27 PM
Really think either go to the TAC for this one, or get a regular router/GW that will work fine.
10-06-2009 03:17 PM
that's what i was hoping to avoid. I know it's not the best setup and a gateway would be the ideal solution but the hardware was already in place and the customer wanted to use it.
Thanks anyway Paulo!
10-07-2009 11:07 AM
Of course it's a bug!
CSCsu26597 Bug Details
Conditions:
Occurs if the software load running on the port is different than the type the port is configured
for in Unified CM. For example, if the load begins with D004, it is a gateway port, so if this port
is configured as a conference bridge or transcoder, it wil not register.
Workaround:
1. Delete the device from CUCM Admin
2. Find out what kind load is already running on the port (Gateway, MTP, or CFB)
3. Go into CUCM Admin and configure the device as the device type that is currently loaded
on the port and in the special load info, put in the name of the load file for the type of device
you want it to become. So if you want to convert it to a Conference bridge, you would enter
C00104000003.
4. Reset the 6608 module
5. Wait for the 6608 to come up and then wait for the port to log that it has asynchronously again
6. Do a 'sh ver' to make sure it has the load you entered in step 3 (e.g. C00104000003). The DSP
load will probably still show the DSP load for the previous device type. This is okay.
7. Delete the new temporary device you created.
8. Re-add the device as the type that you really want the port to be (e.g. conference bridge).
9. Reset the module again
10. After a couple of minutes, the port should reset asynchronously after it gets the new DSP load
and then should come back up and register.
10-07-2009 01:20 PM
For those of you that may have similar problems, there is another bug with the same symptoms for some of the earlier versions of CUCM 7: CSCsu08180
-nick
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: