Monitoring Firmware Upgrade via Peer-Firmware-Sharing

Unanswered Question
Aug 20th, 2010

Hello Experts,

I will be upgrading firmware on approximately 150 phones at a remote site this weekend via Peer-Firmware-Sharing due to bandwidth restraints.  I've never used this method for upgrading firmware so I'm a little in the dark as it relates to monitoring the process.  Just so everyone knows, I have already enabled this feature on all the phones and the new firmware version has been installed on all servers in the cluster (version 7.1.2).  My question is, what is the best way to monitor the process?

Thank you in advance for your advise and wisdom.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
philip.e.denton Fri, 08/20/2010 - 10:29

Once you reset the device pool you could just watch for all phones to reregister and make sure your count stabilizes.

Are you making the version you're upgrading to the default firmware version for your deployment?  I believe you can run a report on phones with non-default firmware versions so you could make sure that count decrements by the number of phones you're upgrading after it's all said and done.

David Hailey Fri, 08/20/2010 - 10:43

I just upgraded about 2000 phones via Peer Firmware Sharing for a customer.  Honestly, the best way to monitor remotely is via RTMT.  Take a note of the registration counts before you reset and then watch the numbers drop accordingly and come back.  It may take some time depending on the speed of the WAN.  Visually (i.e., standing in front of the phones) you can see the Peer Firmware Sharing process taking place and sort-of keep tabs on what is occurring for a group of phones but that's not always feasible.  Technically speaking you should see fewer hits overall on the TFTP counters as well but if you don't have data to compare to then this won't mean much.  I know the non-default firmware report in CCM 4x was of little use as it only looked for phones that were hard-coded via the device settings to use a non-default load.  I believe the same is true today in 7x; however, I've just grown accustomed to not using that data (or using it very rarely) so I could be wrong there.


Please rate helpful posts!

philip.e.denton Fri, 08/20/2010 - 10:55

Unfortunately I don't have a lot of first-hand experience with remote firmware upgrades.  I was hoping with the non-default firmware option that you'd be able to verify that the firmware actually took after you performed the upgrade (by checking pre- and post-upgrade counts).  Other than just hoping the upgrade took I was curious if there was a way to verify other than webbing into a random sampling of phones and checking?

williams-keith Fri, 08/20/2010 - 10:56

Thanks for the reply Philip!  I am aware of the information you provided, I was hoping to gain more of an inside look to the upgrade process if it exists.  Something like a debug tftp would give you but since the phones use each other and not the TFTP server, a debug TFTP on the gateway won't show me the process.  Make sense?

Aaron Harrison Fri, 08/20/2010 - 12:10


Well - with regard to monitoring the process to see how the cogs work together, the only way you'll be able to see that is to SPAN the VLAN to a a wireshark session and then spend an hour or two drinking strong coffee and analysing flows... it's distributed nature means you can't just watch what happens on the server.

The other way would be to see how many hits you get on a given .loads file on the TFTP server logs, compare that to the number of phones, and then verify whether or not the phones upgraded...

I have written a little app that goes off and verifies running firmware loads on the phones against system default firmware loads (mainly to verify whether all is well at customers who are falling foul of Cisco's recent slip up with the phone firmware signing)... just looking for somewhere to host it at the moment..


David Hailey Fri, 08/20/2010 - 12:22

Aaron, well said. That's what I was alluding to in my earlier post. There are ways to "monitor" the process but they aren't necessarily intuitive or complete. As far as comparing firmware data, you can actually scrape the data via the web interface of the phones but this would require a custom script to gather the info. This is probably along the lines of what Aaron is referencing as well.


Please rate helpful posts!

philip.e.denton Fri, 08/20/2010 - 12:55

Thanks for the vote, guys.

Just thinking way out of the box here but if the 2000 phones were all at one site (and in adjacent subnets) rather than setting up wireshark (since he said he's remote) could he setup an ACL that would match TFTP traffic and then keep an eye on ACL matches?  Obviously it wouldn't tell you intuitively how much traffic was flowing but you could get a pretty good idea by issuing the "show" command over and over again...


This Discussion

Related Content