CUCM registration of a WS-X6608 Module

[mattcalderon]

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

[mattcalderon]

FYI

We have used the 2 links below to enable troubleshooting but to no avail.

http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a0080153327.shtml#registration1

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a00801152b9.shtml#creating_catalyst_gtway_callmanager4.x

[paolo bevilacqua]

Really think either go to the TAC for this one, or get a regular router/GW that will work fine.

[mattcalderon]

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!

[mattcalderon]

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.

[Nicholas Matthews]

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