Showing results for 
Search instead for 
Did you mean: 

Peer Firmware Sharing

Anyone have any information on Peer Firmware Sharing in CCM 4.1.3? I am finding little information on the subject.

Do you need to enable it on all phones in the subnet or just one phone? How does the phone know that the other phones are requesting a firmware file? Isn't it a unicast TFTP request or does CCM redirect the request to the local phone with Peer Firmware Sharing enabled?

Hall of Fame Community Legend

Hi Mike,

I have looked into the new functionality and I beleive it was actually added in the release of the CCM 6.x train, it is not available in any previous releases :(

Peer Firmware Sharing

The Peer Firmware Sharing feature adds support for image upgrade optimization for the Cisco Unified IP Phones. When enabled on a root IP phone, Peer Firmware Sharing designates the phone to make a request for an image file. This establishes a transfer hierarchy and transfers the firmware image file from the root IP phone, down to the other IP phones in the hierarchy.

Peer Firmware Sharing also allows for the designation of a remote logging machine, a Log Server, for debugging Peer Firmware Sharing firmware image update logs that are sent to the remote logging machine.

Peer Firmware Sharing remains disabled by default. To enable peer firmware sharing to upgrade firmware for a few phones, in Cisco Unified Communications Manager Administration,

choose Device > Phone > Add New. Then, from the Phone Configuration window, choose Peer Firmware Sharing from the Product Specific Configuration Layout section.

Supported Cisco Unified IP Phones (SCCP and SIP)

7971G-GE, 7970G, 7961G-GE, 7961G, 7941G-GE, 7941G, 7911G, 7906G

Supported Cisco Unified IP Phones (SCCP only)


BAT Considerations

To use Peer Firmware Sharing to upgrade firmware for many phones at once, set the Peer Firmware Sharing field in the Phone Template window of the BAT (Bulk Administration > Phones > Phone Template).

Release Notes for Cisco Unified Communications Manager Release 6.0(1)


"it was actually added in the release of the CCM 6.x train"

I agree, the newer 6.x documentation mentions the Peer Firmware Sharing. But in the 7961/41G Phone release notes it states that you can use AXL for CCM 4.1(3), 4.2(3) and 4.3(1). If you read the AXL release notes, the CCMPPID.exe is a PC program that automates the task of enabling Peer Firmware Sharing on a wide range of phones. I can also enable the Peer Firmware Sharing in my CCM version (4.1.3).

I have enable this on a few phones in my production environment and didn't notice any improvement in speed with the phones upgrading across a T1 WAN. I will set this up in my lab and see if i can sniff the traffic and see debug whats going on if anything.

Here is a cut form the release notes:

Configuring Peer Firmware Sharing

By default, Peer Firmware Sharing is not enabled. To enable peer firmware sharing for a few phones, enable Peer Firmware Sharing settings, from Cisco Unified Communications Manager, choose Device > Phone > Add New. Then, from the Phone Configuration window, choose Peer Firmware Sharing from Product Specific Configuration.

To configure Peer Firmware Sharing for multiple phones at once:

• For Cisco Communications Manager 5.0 and later, enable Peer Firmware Settings in the Phone Template window of the Bulk Administration Tool.

• For Cisco Unified Communications Manager 4.1(3), 4.2(3) and 4.3(1), download an AXL script.

-Go to the following URL:

-Download ccmppid.exe and ccmppid readme.

Install ccmppid.exe according to the readme file instructions.

Rising star


The same checkbox is also available in CUCM4.2(3) but I haven't tested if it works in any version. Do you think it would be enough to check the box on the phones in one DP to have it working?




has anyone used this in a real situation ?




I'm testing it in a lab environment and it doesn't seem to work.

I don't know how it should work exactly (not much documentation on it) but after enabling the check box on several phones, I can see with a sniffer that when I plug a new phone it sends a broadcast packet requesting the firmware but it gets no reply from anyone, although there are several phones already running the firmware requested.

After a few tries, the phone asks the firmware to the CM

Anyone has seen it working??? Is there any other configuration than the Peer Firmware sharing option on the Device?

Thanks in advance



With TAC's help I finally got this working in my lab. I found that the peer firmware sharing feature only operates as the phone is booting. If this feature is enable on all the phones in a subnet (CDP neighbors) and all the phones reset at the same time, one will pull down the firmware and the other phones will detect this and wait till the master pulls the file. Then then the file gets distributed to the peers. The peers sit at 100% loading on the firmware status page while the master pulls the file. Then they quickly pull the next file and sit at 100% while waiting for the next file. I also discovered that the master will change for each file, so it is entirely random of which phone will actually contact the TFTP server and pull the code for the peers.

We will be upgrading the code in a week and I'm hoping all will go well.



Hi all,

As I'm understanding your words, Troy, PFS only works when many phones need their firmware at the same time. Is that right ?

I mean, if just a phone upgrades its firmware (and another phone with the new firmware is already present on site), the PFS will not work. They need to upgrade at the same time in order to use this functionnality.


After many tests,

We finaly made this working. In fact it seems to be quite simple.

If 2 or more phones have to download the same firmware at the same time, typicaly when you change the default template for a phone model, and are Peer Firmware Sharing enabled, they "elect" a root phone which will download the firmware. The other are stuck in the download state waiting the root phone to finish its download. Each time the root phone downloads a file, the others downlad it localy. This functionnality allows you to save brandwith, but that's all.

If a phone is already updated on the site, it'll not participate and will not be the root phone. This behaviour is quite strange. In our case with a lot of latency, the download last something like half an our (as all the frames are acked in tftp). All the "child" phones are stuck during this whole time. PFS allows us to save brandwith but as all the phones are all stuck for a long time we still have to do the migration the night.


Is there any way to check in syslog server that PFS is working correctly.?


Does this only work if CDP is enabled?  We have a mixed vendor environment with Cisco and Alcatel swtiches.  All the phones connect to Alcatel switches and CDP was causing issues for us on the Alcatel and so we had to turn off CDP on the switch port.  Will Peer Firmware Sharing still work with CDP disabled?



Maybe take a look at Bill's blog covering how this feature works.

No mention of CDP there... and I'm not sure that it would be any use - CDP is a 'connected things discovery' protocol, i.e. it tells a switch that a phone is connected and vice versa - but two phones will not normally see each others' CDP messages.



Please rate helpful posts...

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

Thanks Aaron.  I wouldn't think CDP would be required either, but when we had to disable CDP on the switch port of the phone, that is when our VAR said that Peer Firmware Sharing would probably break. 


I believe that your VAR is incorrect. CDP doesn't play a role in peer firmware sharing. Phones build the distribution tree using UDP broadcasts to establish peer relationships. Distribution trees are only built between "like" models (e.g. 7945/65 stations and 7941/61 stations would establish two separate trees) and the trees are only built within a given subnet (ala broadcast). Also, Aaron is correct CDP is a link level communication and CDP neighbors are only established on directly connected links.




HTH -Bill (b) (t) @ucguerrilla

Please remember to rate helpful responses and identify

Content for Community-Ad