[cisco-voip] Peer Firmware Sharing

[Jason Roysdon]

Yes, I wish Cisco had this as well.  I just did a small 11 site remote
install yesterday, and I really wish Peer Firmware sharing worked right
away.  It took forever for those 11 phones to upgrade out of the box,
even though I'd already added them via BAT and their device
configurations had Peer-to-Peer on (but again, they won't get it until
they download the config).

Another low-tech solution would be to pay a temp worker or someone with
spare time to sit at the core site and plug in phones so they can
upgrade and get the Peer-to-Peer feature enabled.  They could unbox a
phone, plug it in, and keep going until they had probably 10-20 phones
going at once and the first phone would be done.  Then just box it back
up and keep going.  It's really lame, but we already pay folks to do
that to pre-build the phones by putting the English sticker on and wire
up the handset to the phone and remove the plastic from the handset
cable and ethernet patch cord.  It sounds stupid to do as it's so easy
to do at the time of install, but when you're doing dozens or hundreds
of phones at once, you can go much faster if all you have to do is take
the phone out and plug in cables and nothing else.  Once you get used to
it like that, it's irritating to have it not be that way - as yesterday
they'd not removed the plastic from the handset cable or ethernet cable.

Steve G wrote:
> Jason,
> Thanks for your detailed response.  Basically this means that the "peer
> firmware sharing" feature is not useful for new installs coming on
> line.  Now that we have that figured out.  I wish there was a doc from
> Cisco with the detailed information that you stated below.  I have been
> unable to find one.
> 
> On Wed, Nov 5, 2008 at 1:24 PM, Jason Roysdon
> <cisco-voip.20081105 at jason.roysdon.net
> <mailto:cisco-voip.20081105 at jason.roysdon.net>> wrote:
> 
>     Sorry that this message won't be threaded right.  I just joined the list
>     so I'm pasting this from the web archive.
> 
>     The trick is that you need the phones to not upgrade right out of the
>     box.  But that's the first thing they check on when they hit the TFTP
>     server ("Do I have the latest version?").  If you were really desperate
>     to do this, you could set up a temp CUCM server to point the new phones
>     to that matched the same firmware as the phones.  That's if the phones
>     all shipped with the same firmware.  They will check with that CUCM
>     server and see they already have the latest firmware and not upgrade.
>     Have the phones already BAT'd in with their MAC addresses and the Peer
>     Firmware Sharing set to on.  Now the phones will all get this setting
>     enabled, and you can re-home them to the real CUCM TFTP server.
> 
>     However, I don't think you'd want to do this unless you had a really,
>     really slow WAN.  The Peer Firmware Sharing only has one "root" phone on
>     a LAN sharing at a time, and I believe that phone can only share to 5
>     phones at a time (I cannot find any docs supporting this 5 phone limit,
>     but I recall hearing this at a Cisco Partner meeting from a badged Cisco
>     CUCM developer).  That'd run very slow for 200 phones.  I suppose a
>     trick you could use would be to set up a VLAN for 200 / 6 phones (34
>     VLANs).  Each VLAN would have one "root" that would download the
>     software and then share to the other 5.  You could even get a
>     complicated system going where you upgraded 5, then moved them over to 5
>     different VLANs.  Keeping the ports shutdown until you had a "root"
>     ready to move to one of the VLANs would keep the phones from coming up
>     too soon.  Sounds very convoluted to me (but I love coming up with
>     elaborate hacks to solve things like this).
> 
>     If you were going to set up a temp server, you might as well just have
>     it local and have the latest firmware (even, say, on a laptop in a VM
>     setting).  Then they can all upgrade right away at 100+mb/s speeds.  You
>     don't even need a CUCM server to do this, just the right files on a TFTP
>     server (or even IOS router running CME, but a router cannot support a
>     huge amount of TFTP upgrades at once either).
> 
>     Given this silliness to get something like this to work, Cisco should
>     have designed the Peer option to be more intelligent and have it on by
>     default - but with it checking to see if it has a 10+mbit connection (or
>     whatever speed seems reasonable) to the TFTP server first.  If it does
>     and is able to download that fast, skip trying to download from a peer
>     and get it from the source.  If not, fall back to selecting a root and
>     having it download from the TFTP server and share - but then also have
>     other roots that can handle the load and share to more phones if the
>     first root is already "full" upgrading 5 phones.
> 
>     Jason Roysdon.
> 
>     > So if I'm deploying 200 phones at a brand new site, how to I use this
>     > feature to speed the deployment of the phones? If the feature is
>     > disabled by default, then when the phone gets auto registered the
>     > feature goes away instantly. (since it found its config, with the
>     option
>     > disabled)
>     >
>     >
>     >
>     > How would I make the feature enabled by default?
> 
>     _______________________________________________
>     cisco-voip mailing list
>     cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>     https://puck.nether.net/mailman/listinfo/cisco-voip
> 
>