cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3376
Views
5
Helpful
10
Replies

CUCM unable to send a CDR or communicate to other server using FTP

kiervin.munoz
Level 1
Level 1

Hi All,

We encountered unusual behavior wherein our configured setting for Billing Application Server Parameters in CUCM suddenly cannot send the CDR going to a server using FTP. It is working before and we just noticed that the sending of CDR has been stop.

For isolation, we configured different setting that will send CDR to the same server using SFTP and the sending of CDR was successful.

We tried to isolate further the issue by using other PC and transfer a file to the same server using FTP and the file sending was successful. With this, we came up that there is nothing wrong in the network.

The next action plan we did, we restarted the Cisco CDR Repository Manager service. After restarting this service, the configured setting for Billing Application Server Parameters is now working again using FTP.

We would like to know what is the cause of the issue regarding FTP in Call Manager? Our version of Call Manager is 8.6.2.20000-2. Is there a bug related to this king of issue?

Thank you.

1 Accepted Solution

Accepted Solutions

Hi Kevin,

I went through the logs.

its seems that you had the following config.

Destination 1 hostname: 10.220.3.115
Destination 1 userid: lcsftp

Destination 2 hostname: 10.220.3.115
Destination 2 userid: cisco   (this seems to be for the testing purpose using SFTP)

It looks like that you restarted the service at 17:25:59.

After this there was just one instance of failure at 17:30:03 for destination 1.

2016-05-11 17:30:03,092 ERROR [Thread-9] cdrrep.FtpManager (FtpManager.java:210) - java.net.SocketException: Connection reset


2016-05-11 17:30:03,092 ERROR [Thread-9] cdrrep.FtpManager (FtpManager.java:223) - SFTP/FTP failed: cdr_StandAloneCluster_01_201605092256_20321 to 10.220.3.115

I can't tell you why it failed as the logs are set to INFO and not Debug.

Also before restarting service i did not see any failure for destination 1 but for destination 2 which is out of the picture.

Please rate if helpful.

Regards,

Adarsh Chauhan


Please rate and mark correct if helpful
Regards,
Adarsh Chauhan

View solution in original post

10 Replies 10

Manish Gogna
Cisco Employee
Cisco Employee

Hi Kiervin,

There are many cdr related bugs in 8.6.2 version but none matches this issue exactly. Ideally you should have collected the cdr traces and contacted TAC for an RCA when the issue was happening. From my understanding if the reports were being sent when you used a different PC then it is likely not a cucm issue, otherwise the behavior would have been the same for all PC's.

Manish

Hi Manish,

Thank you for the information regarding the bug.

We use different PC and use FTP but issue still encountered, so we are isolated that the issue might be in CUCM since we resolved it after restarting the CDR reporsitroy manager service. We just want to know now if what is the cause of the issue. 

Adarsh Chauhan
Level 3
Level 3

Hi Kiervin,

If the issue has happened recently you should collect Repository manager traces of that time frame.

Just look around that time stamp and you should be able to figure out the failure in them.

The traces are easy to read.

Regards,

Adarsh Chauhan


Please rate and mark correct if helpful
Regards,
Adarsh Chauhan

Hi Adarsh,

Already collected the CDR Repository logs during the timestamp of the issue. I uploaded the logs on this thread. I already checked it however i did not saw specific details or information regarding the cause of the issue. Appreciate if you can also look at the logs.

Thanks

Hi Kevin,

I went through the logs.

its seems that you had the following config.

Destination 1 hostname: 10.220.3.115
Destination 1 userid: lcsftp

Destination 2 hostname: 10.220.3.115
Destination 2 userid: cisco   (this seems to be for the testing purpose using SFTP)

It looks like that you restarted the service at 17:25:59.

After this there was just one instance of failure at 17:30:03 for destination 1.

2016-05-11 17:30:03,092 ERROR [Thread-9] cdrrep.FtpManager (FtpManager.java:210) - java.net.SocketException: Connection reset


2016-05-11 17:30:03,092 ERROR [Thread-9] cdrrep.FtpManager (FtpManager.java:223) - SFTP/FTP failed: cdr_StandAloneCluster_01_201605092256_20321 to 10.220.3.115

I can't tell you why it failed as the logs are set to INFO and not Debug.

Also before restarting service i did not see any failure for destination 1 but for destination 2 which is out of the picture.

Please rate if helpful.

Regards,

Adarsh Chauhan


Please rate and mark correct if helpful
Regards,
Adarsh Chauhan

Hi Adarsh,

Thanks a lot for the information and checking.  Yup, when I also checked the logs, i can't see a detailed information to identify the reason of the issue. Actually the one that you have checked was the time when we are isolating the issue by recreating other server having username of lcsftp and cisco.

The other folder from the logs i attached which was dated on May 4, this is the time wherein no configuration changes made while we are encountering the issue. However there is no detailed information also on those logs.

With this, is it possible to turn on level of the logs from info to debug? Will it affect the production of CUCM or its utilization if the CDR Repository Manager is set to debug level?

Again, Thank you so much Adarsh for the help.

Hi Kiervin,

You can turn level of logs to DEBUG.

It won't affect your production.

Please rate if helpful and give a closure to this thread.

Regards,

Adarsh Chauhan


Please rate and mark correct if helpful
Regards,
Adarsh Chauhan

Hi Adarsh,

Tried checking the trace for CDR Reporsitory Manager and I have one question regarding the level of trace.

Do we need to choose Debug level or Fatal?

Thanks.

Hi Kiervin,

It would be debug.

Regards,

Adarsh Chauhan


Please rate and mark correct if helpful
Regards,
Adarsh Chauhan

Hi Adarsh,

Thanks a lot. Really appreciate your help.