cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2294
Views
0
Helpful
11
Replies

IP Phone showing upgrading

yadwindersingh
Level 1
Level 1

Dear All,

 

I am using Cisco 7911,7906 IP phones with CUCM 6.1.2 and i am facing an issue. When factory reset the IP phone it continuously showing upgrading screen. checked captures from TFTP server :

 

09:50:05.692013 10.10.12.91.49481 > TFTP SERVER.TFTP Server:  29 RRQ "term06.default.loads"

09:50:05.692279 TFTP SERVER.60623 > 10.10.12.91.49481: udp 516 (DF)

09:50:09.299247 TFTP SERVER.60623 > 10.10.12.91.49481: udp 516 (DF)

09:50:09.691027 10.10.12.91.49481 > TFTP SERVER.TFTP Server:  29 RRQ "term06.default.loads"

09:50:09.691272 TFTP SERVER.60626 > 10.10.12.91.49481: udp 516 (DF)

09:50:13.339316 TFTP SERVER.60626 > 10.10.12.91.49481: udp 516 (DF)

09:50:13.339382 TFTP SERVER.60623 > 10.10.12.91.49481: udp 516 (DF)

09:50:13.691166 10.10.12.91.49481 > TFTP SERVER.TFTP Server:  29 RRQ "term06.default.loads"

09:50:13.691396 TFTP SERVER.60631 > 10.10.12.91.49481: udp 516 (DF)

09:50:17.379438 TFTP SERVER.60626 > 10.10.12.91.49481: udp 516 (DF)

09:50:17.379477 TFTP SERVER.60631 > 10.10.12.91.49481: udp 516 (DF)

09:50:17.379505 TFTP SERVER.60623 > 10.10.12.91.49481: udp 516 (DF)

09:50:17.690995 10.10.12.91.49481 > TFTP SERVER.TFTP Server:  29 RRQ "term06.default.loads"

09:50:17.691238 TFTP SERVER.60636 > 10.10.12.91.49481: udp 516 (DF)

09:50:20.729473 TFTP SERVER.6970 > 10.10.12.91.49191: S 1029959837:1029959837(0) ack 3011509065 win 5840 <mss 1460> (DF)

09:50:20.729574 10.10.12.91.49191 > TFTP SERVER.6970: R 1:1(0) ack 1 win 5840

09:50:21.419515 TFTP SERVER.60626 > 10.10.12.91.49481: udp 516 (DF)

09:50:21.419552 TFTP SERVER.60631 > 10.10.12.91.49481: udp 516 (DF)

09:50:29.499742 TFTP SERVER.60631 > 10.10.12.91.49481: udp 516 (DF)

09:50:29.499772 TFTP SERVER.60623 > 10.10.12.91.49481: udp 516 (DF)

09:50:29.499820 TFTP SERVER.60636 > 10.10.12.91.49481: udp 516 (DF)

09:50:33.539804 TFTP SERVER.60626 > 10.10.12.91.49481: udp 516 (DF)

09:53:45.442218 10.10.12.91.52139 > TFTP SERVER.6970: S 956502415:956502415(0) win 8192 <mss 1340>

09:53:45.442289 TFTP SERVER.6970 > 10.10.12.91.52139: S 1287934651:1287934651(0) ack 956502416 win 5840 <mss 1460> (DF)

09:53:45.975035 10.10.12.91.52139 > TFTP SERVER.6970: S 956502415:956502415(0) win 8192 <mss 1340>

09:53:45.975055 TFTP SERVER.6970 > 10.10.12.91.52139: S 1287934651:1287934651(0) ack 956502416 win 5840 <mss 1460> (DF)

09:53:46.975046 10.10.12.91.52139 > TFTP SERVER.6970: S 956502415:956502415(0) win 8192 <mss 1340>

09:53:46.975066 TFTP SERVER.6970 > 10.10.12.91.52139: S 1287934651:1287934651(0) ack 956502416 win 5840 <mss 1460> (DF)

09:53:48.533939 TFTP SERVER.6970 > 10.10.12.91.52139: S 1287934651:1287934651(0) ack 956502416 win 5840 <mss 1460> (DF)

09:53:48.975040 10.10.12.91.52139 > TFTP SERVER.6970: S 956502415:956502415(0) win 8192 <mss 1340>

09:53:48.975060 TFTP SERVER.6970 > 10.10.12.91.52139: S 1287934651:1287934651(0) ack 956502416 win 5840 <mss 1460> (DF)

09:53:52.975025 10.10.12.91.52139 > TFTP SERVER.6970: S 956502415:956502415(0) win 8192 <mss 1340>

09:53:52.975043 TFTP SERVER.6970 > 10.10.12.91.52139: S 1287934651:1287934651(0) ack 956502416 win 5840 <mss 1460> (DF)

09:53:54.534069 TFTP SERVER.6970 > 10.10.12.91.52139: S 1287934651:1287934651(0) ack 956502416 win 5840 <mss 1460> (DF)

 

 

 

Please check and suggest how can i resolve this issue.

11 Replies 11

Manish Gogna
Cisco Employee
Cisco Employee

Check if the TFTP server is reachable from the IP phone. Try a restart of TFTP service , try connecting the phone to a good known working switchport where another ip phone is working fine. Is the issue being faced on all phones that have been factory reset or just one? If it is only one then you may try the factory reset one more time.

HTH

Manish

Thanks manish for your reply.

 

Actually i tried to restart the TFTP services as we as TFTP server. Also checked by connecting phone with other switch port on which other ip phone is working fine. i am facing the same issue everytime when i factory reset any ip phone but after 3-4 days i automatically get upgraded. 

Hi Yadwinder,

As you are still running cucm 6.1.2 i would suggest to at least upgrade the cucm to latest 6.1.5 ( although it will still be end of support by TAC ) to rule out any existing bugs on this version.

HTH

Manish

yeah i also think so but this is not in my hand only management can do so. what i can do is effort to resolve the issue. so please suggest if anything i can do with current setup.

Not much i can suggest further with this setup, only additional thing that comes to my mind is to specify the latest phone load that is installed on your cucm cluster in the 'Phone Load Name' field of these phones on cucm phone configuration page.

 

This will hard code the config file with the latest load and should prevent the phone from making upgrade file requests unless there are some bugs or other issues with the setup.

HTH

Manish

did the same but issue still persist

Charles Hill
VIP Alumni
VIP Alumni

We experienced a similar issue after a callmanager upgrade.

 

All phones were stuck at upgrading.  The existing phone firmware could not upgrade directly to the new firmware.  Phones needed an interim step firmware upgrade before they can be successfuly upgraded to the new firmware.

 

If an interim step upgrade is needed, it should list the step in the Release notes.

 

Hope this helps.

Hi Charles,

If the phones are showing an Auth Fail error then surely what you said will apply. AFAIK most of the IP phone models need to first upgrade to an intermediate 8-5-2S load before they can be upgraded to a higher firmware, else the Auth fail message will be seen.

Manish

Thanks for the info.  I seem to learn something new every day.

 

Do you think packets could be dropped due to mtu size? 

udp 516 (DF)   ********* I'm assuming DF is don't fragment?

Hi Charles,

Fragmentation and MTU size are related. Fragments are reassembled only by the receiving application. Therefore, its an inefficient use of the network. Only IP packets with the Do not Fragment (DF) bit not set can handle fragmentation well.

No fragmentation is required if the fragment size is larger than the link MTU size. For example, for a T1 link with a 1500-byte MTU, the fragment size is 1920 bytes. Therefore, no fragmentation is required. The packet fragmentation size should never be lower than the VoIP packet size. Do not fragment VoIP packets. Fragmenting these packets causes numerous call setup and quality issues.

http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/20371-troubleshoot-qos-voice.html

HTH

Manish

 

 

Hey Manish,

Thank you for the info, but I understand that MTU and DF bit is related and how they work.  I was asking do you think Packets may be getting dropped causing the 3 -4 days to upgrade?

 

I would also suggest doing a packet capture on the phone's switchport.  It may shed some light on the 3 -4 day to upgrade.

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: