The slowness of Firmware upgrade

[halit.oner]

Hey All,

We applied firmware upgrade to 894x phones and upgraded them from SIP  9.3.2.12 to SIP 9.3.4.17   in our 67 branches.  each  branches   has 6-7  894X phones and   Data Line is    2 Mbit or  5 Mbit for each branch

 The issue is that the upgrade process takes too much time. Some of the phones downloaded the firmware file in 100 minutes and some other in 150 minutes .

Our network team monitored the traffic and told us that they didn’t observe any saturation or network related issue.

We want to find out why the upgrade takes so much time.

Maximum Serving Count: 1500
CUCM version: 9.1.2.13900-10

Total Branches: 900

Total Phones :  13000

Standalone TFTP

[Mohammed al Baqari]

Hi,

1. what TFTP server are you using?

2. What is the average latency between your TFTP server and the branches? Try to use ping with size 1500 bytes

3. Any QoS settings on the WAN links caping the file transfer protocols kbps?

4. If you perform copying from TFTP server to a phone on the same LAN, what is the speed you are getting?

[halit.oner]

Hi Mohammed,

Normally we can have 4 Video communication  in the same time, which means we don't have network slowness  normally,

I attached  console logs on below,

1) We are using standalone TFTP on the headquarter

2)  ping 10.216.14.24 source GigabitEthernet0/0.11 size 1500
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.216.14.24, timeout is 2 seconds:
Packet sent with a source address of 42.173.193.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/26/28 ms

3) it's being used only  for voice , that's why there is no QOS

4) When I tried to upgrade firmware in the same location with TFTP it  took  2.5 -3 minutes.

[Jonathan Schulenberg · Accepted solution]

The most common culprit of this is that TFTP traffic is by default tagged with CS3 (configurable under CUCM Enterprise Parameters as the DSCP for Phone Configuration parameter. Most classic QoS models suggested assigning a comparatively small amount of bandwidth to the CS3 class which became a problem when it was time for a phone firmware update.

Are you absolutely certain there is no QoS in the path between the phones and CUCM that could be shaping this traffic?

Also verify that Peer Firmware File sharing is enabled on all of the phones and that all phones in a VLAN reboot together. This will further minimize the chance of problems as only one phone will pull the firmware off of TFTP and then share it with its neighbors.