IP Phone showing upgrading

[yadwindersingh]

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.

[Manish Gogna]

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

[yadwindersingh]

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. 

[Manish Gogna]

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

[yadwindersingh]

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.

[Manish Gogna]

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

[yadwindersingh]

did the same but issue still persist

[Charles Hill]

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.

[Manish Gogna]

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

[Charles Hill]

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?

[Manish Gogna]

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

[Charles Hill]

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.