cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3317
Views
20
Helpful
6
Replies

CUCM TFTP server connection problem

Vazhenin_RS
Level 1
Level 1

Hello Experts!

 

TFTP Server suddenly stopped working,
The TFTP service is active, the configuration has not changed since when everything was working.
The server was restarted several times, but it didn't help.
DHCP is configured correctly with option 150, all phones receive a CCM and TFTP address.

Phones themselves are available, ping goes both ways.
When I try to manually download a file from TFTP using a Windows tftp client, I get the "Connect request failed" error and in Wireshark Dump, i can see that the server will respond to a read request with ICMP with a Port Unreachable error.

 

Thanks all for help,

 

Vazhenin Roman

1 Accepted Solution

Accepted Solutions

Cisco IP Phones are stubborn. If they are unable to reach a TFTP server to get information, they will use their 'last known good' config stored in their memory and go with that. This is why your phones are registered and working even though the TFTP service is messed up.

And there is absolutely a problem with the TFTP server. If you look at the header line in your trace file, it reads: "18:52:19.081 HDR|02/22/2020 TFTP,StandAloneCluster,ala-hq-ccm,Error,8.6.1.20000-1"

(This is also at line 8146 where it looks like the TFTP server was rebooted maybe? and also later where the service itself was restarted.)

If you look at the section starting at line 518, you will see (what I assume to be) an MGCP gateway attempting to download a config file and failing. The request is reaching the TFTP server, but as far as the TFTP server is concerned the file is not found (see line 514) and so cannot service the request.

Ditto with a number of other requests, such as SEP002155D69F75 (around line 8663) requesting to download its config file (and then requesting the XML Default file). The TFTP server says it's serving the file but is receiving no ACK and so re-serves it repeatedly. And again at line 9610 with device SEPEC44761E5CB5.

The trace also indicates that the TFTP server is unable to build new files (look for "BuildFIles").

So...I think it is possible that the TFTP database itself is corrupted rather than this being a connection problem.

Here is what I would try:

If you have more than one server in your cluster, try activating the TFTP service on a different server to see if it will build a stable set of records. I'd give it a 50-50 chance of doing so. It will depend on whether the new TFTP server will copy the files from the existing one (which, of course, it can't) or if it will try to build a new set of files. So if you can, activate the service and then set one phone for that server as its option 150 and see what happens. If it works, that's great and you can *maybe* solve your problem by deactivating and reactivating the TFTP service on the original server (with some time in between to purge the database and maybe reboot it as well). I make no promises on that, though, as I have never run into this exact problem before.

If activating the TFTP service on a new server does not allow devices to download config and load files, then it's time to call TAC. You may have to do a full restore of the TFTP server (but from what backup?), or rebuild it from scratch and allow the pub to build all new config files.

Good luck with this. I'd love to know what happens, so please post again - especially if you get a solution - but also if I/we can answer more questions.

Maren

 

 

View solution in original post

6 Replies 6

Andrew Skelly
Level 7
Level 7

Are you specifying a port on your Windows FTP application?  If so, which port are you using?

Please rate helpful posts by clicking the thumbs up!

Vazhenin_RS
Level 1
Level 1

Hello Andrew,

No, I am using standart TFTP port 69.

Can you pull the trace file for the TFTP Service and post it? Also, if you can, post the log file of a phone that is not registering.

Maren

Hello Maren,

Thanks for your reply!

All phones are registered successfully and can make calls.
However, they cannot update the configuration and receive firmware from the TFTP server.
CUCM Stand Alone Cluster works in non-secure mode.
I have attached a dump from CUCM Publisher and Trace from TFTP Service.

Cisco IP Phones are stubborn. If they are unable to reach a TFTP server to get information, they will use their 'last known good' config stored in their memory and go with that. This is why your phones are registered and working even though the TFTP service is messed up.

And there is absolutely a problem with the TFTP server. If you look at the header line in your trace file, it reads: "18:52:19.081 HDR|02/22/2020 TFTP,StandAloneCluster,ala-hq-ccm,Error,8.6.1.20000-1"

(This is also at line 8146 where it looks like the TFTP server was rebooted maybe? and also later where the service itself was restarted.)

If you look at the section starting at line 518, you will see (what I assume to be) an MGCP gateway attempting to download a config file and failing. The request is reaching the TFTP server, but as far as the TFTP server is concerned the file is not found (see line 514) and so cannot service the request.

Ditto with a number of other requests, such as SEP002155D69F75 (around line 8663) requesting to download its config file (and then requesting the XML Default file). The TFTP server says it's serving the file but is receiving no ACK and so re-serves it repeatedly. And again at line 9610 with device SEPEC44761E5CB5.

The trace also indicates that the TFTP server is unable to build new files (look for "BuildFIles").

So...I think it is possible that the TFTP database itself is corrupted rather than this being a connection problem.

Here is what I would try:

If you have more than one server in your cluster, try activating the TFTP service on a different server to see if it will build a stable set of records. I'd give it a 50-50 chance of doing so. It will depend on whether the new TFTP server will copy the files from the existing one (which, of course, it can't) or if it will try to build a new set of files. So if you can, activate the service and then set one phone for that server as its option 150 and see what happens. If it works, that's great and you can *maybe* solve your problem by deactivating and reactivating the TFTP service on the original server (with some time in between to purge the database and maybe reboot it as well). I make no promises on that, though, as I have never run into this exact problem before.

If activating the TFTP service on a new server does not allow devices to download config and load files, then it's time to call TAC. You may have to do a full restore of the TFTP server (but from what backup?), or rebuild it from scratch and allow the pub to build all new config files.

Good luck with this. I'd love to know what happens, so please post again - especially if you get a solution - but also if I/we can answer more questions.

Maren

 

 

Hello Maren,

 

Unfortunately, we do not have subscribers in our cluster.

Therefore, the decision was made to restore publisher from a backup. Moreover, the backup was created from a system in which the tftp server was already broken.

Fortunately, this helped, the publisher was fully restored and is functioning correctly.

 

Thank you very much for your help!

Getting Started

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: