Testing Peer Firmware Sharing at single remote site - please check my plan

[jonathanwalton]

I have many remote sites that need firmware updates. None of the phones are band new. I would like to test the Peer Firmware Sharing function on 7945 phones at a specific remote location (1 subnet), but do not want to update all of the 7945 phones in the cluster. This is how I was planning on doing this, please let me know if there is an easier way:

• 1. Load firmware cop files to pub and subs, restart TFTP service on pub and sub.
  
• 2. The device defaults for the 7945 should now show the new firmware file, and I’m at risk of any 7945\7965 in the cluster grabbing the new firmware simply because it rebooted.
  
• 3. Use the BAT tool to enable Peer Firmware Sharing on all phones at a specific remote site, reboot specified phones. As I understand it, this will update a single phone at the remote site, and then host the firmware for the other phones in the same subnet.
  
• 4. Assuming the Peer Firmware Sharing worked, I would then use the BAT tool to explicitly specify the NEW firmware phone load on the phones that were just updated.
  
• 5. Revert the CUCM device default for the 7945\7965 to previous firmware version, restart tftp services on pub and subs. This should keep other 7945s from grabbing the new firmware if they are rebooted.
  

[Leonardo Santana]

Just to add to your plan take a look on this documentation:

http://www.cisco.com/en/US/products/hw/phones/ps379/products_tech_note09186a0080a277a3.shtml

Rate this if helps you

Regards

Leonardo Santana

[jonathanwalton]

Thanks for the reply, but your link talks about upgrading indiviudal phones directly from the CUCM, in my case, the WAN.  Although I use a portion of the directions in your link to ensure the newly updated phones do not revert back, I'm looking for advice\conformation on "Peer Firmware Sharing".  Lol - 2 stars for you

[Leonardo Santana]

With this procedure you can guarantee that the ip phones will not get the new firmware until you configure the ip phone to download this firmware

Take a look on this other link it might help you:

http://www.netcraftsmen.net/component/content/article/70-unified-communications/758-options-for-distributing-cisco-phone-firmware.html

Regards

Leonardo Santana

[jonathanwalton]

I've read that link as well.  If the new firmware is the device default in CUCM, why do you say the phones will not take it after a reboot?

[Leonardo Santana]

I dont unterstand your question?

"Why do you say the phones will not take it after a reboot?"

[jonathanwalton]

You said my procedure is guaranteed to not grab the new firmware until the phone is configured to do so. However in step 1-2, I said the new firmware will be the "device default" (device->device settings->device default) , and therefore on a reboot the phone will update.

I guess I need to understand the following question:

"Will Peer Firmware Sharing work if the "device default" firmware is not set to the new version, but the group of phones all have the new firmware load explicitly set? Or does Peer Firmware Sharing have to use the "device default" firmware version?"

*update*

For what it's worth, I just setup a lab with 4x 7945 phones on the same subnet with the same firmware.

1. I put the 4 devices in their own device pool.
   
2. Using the BAT tool, I enabled the peer firmware sharing option and reset
   
3. Using the BAT tool, I explicitly set the new firmware load directly on the phones and rebooted the phones
   
4. They all rebooted, and downloaded the firmware at the same time, and finished at the same time (within 5 seconds of each other)
   

So it appears Peer Firmware Sharing does not work by explicitly specifying the firmware load on the phone. I assume that means the new firmware file must be the "device default".

I will try using my original method after hours in a test group.

[Rob Huffman]

Hi Jonathan,

Thanks for posting up with your lab results! +5 for this good work.

Our experience with PFS would agree with your original plan 100%. It is cumbersome

but at least the upgrades can be controlled and valuable bandwidth preserved

Cheers!

Rob

"Always movin' ahead and never lookin' back" - Springsteen

[Gengad]

Hi Jon,

I hope you well,

I know it has been a long time since you did this experiment. I would appreciate if you could help me here.

I am upgrading remote phones a cross Europe, BW is a major issue with me at the moment. I want to use PSF. I got my phones connect to VPN concentrator going through ASA Firewall.

I did the following;

1. Enabled PSF and checked the box "Override Common Settings".

2. Enabled PSF for one phone which participates to download from step 1. I also checked  "Override Common Settings".

3. I downloaded a new firmware on my phone from tftp.

4. My expectation was that step 2 phone will automatically download the firmware. That didn't happen.

Can you please very kindly advice me where I am going wrong. I also asked Security team to unblock port 051 CPPDP.

Thanks

[Jaime Valencia]

From the original thread, and what you mention, there are a few points that are not quite accurate.

A) The phones require more than one file for upgrading the phone FW, and this does NOT mean that a single phone will be the source for all of them, chances are, you might end up with 2+ phones downloading the necessary files, and seeding them. You have absolutely no control on this point, phones will randomly decide.

B) This was mentioned, but just to clarify, as they rely on a variant of CDP to do this, this only works within the broadcast domain where they are, meaning, per subnet.

C) You need to reboot all the phones you want PFS to be part of, at the same time, so they can see that there are many endpoints wanting the same FW, and then trigger the PFS behavior. You cannot download the FW to one phone, and then use it to seed the FW.

If you're having problems downloading the FW to a single phone at the remote site, I'd start by looking at FW, ACLs, etc.

[Gengad]

Hi Jaime,

Long time we haven't spoken, Thanks for guiding us in the right direction. Your help has been noticed across Cisco Support. Whatever you give I can assure you that you will get it back from somewhere.

First point you made was that I need to get 2 phones downloaded with the correct firmware. This is DONE

CDP is enabled in on the phone. My next question is do we need it also on the switch level? The phones are on the same subnet.

I have rebooted the phones and nothing happen. My next question is on the phone you have an option where is says load server: Do I put the IP address of the phone where the firmware resides? Or do I leave it blank? If yes then which IP address do I need to provide out of the 2 phone which has the latest firmware?

On the Device >>>> Device Setting >>>> Device Default , on the inactive load do I put the latest firmware as inactive?

I also turned off TFTP Server to see if the phone actually downloading the firmware from the phone not the TFTP.

Can you please very kindly assist me and tell me where I am going wrong with this. Currently I am testing this process in the LAB before we do it in production.

I look forward to hear from you soon.

Many Thanks

[Jaime Valencia]

You think you get to choose which phones will "seed" the FW, but you have absolutely no control, it's not working, because it's not supposed to work the way you're doing this.

Those two phones that have the FW, will no longer work with PFS as long as they have the same load you want the other phones to have.

You need to reset a LOT of phones (same model/same subnet) and they (once again, you have absolutely no control over this, you just get to watch) will see thru that CDP variant that there are a lot of them trying to get the same FW, then one of them will say "I will get this file", and in all probabilities, other phones will say the same, with all the files you need. Once they have finished downloading the file they're supposed to download, then, they will say, hey you guys, I have file.jar for example, get it from me, and the same for all the other files.

You don't need to configure absolutely anything else, besides enabling PFS.

Load server is for another TFTP server where files are hosted.

EDIT: I have this explained in my wiki as well

http://docwiki.cisco.com/wiki/Endpoints_FAQ#How_can_I_configure_PFS_.28Peer_Firmware_Sharing.29.3F.3F