[cisco-voip] Peer Firmware Sharing

[Jason Roysdon]

I mentioned this in my original post:
"...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)."

If you can control the amount of phones coming online at once, CME is
probably fine for upgrading.  But I've seen CME freak out on smaller
routers with large numbers of phones.  Plus, CME has low caps for max
phones (depends on router models).  I actually don't recall exactly,
since we don't do anything over 50 phones with CME since CUCMBE has been
out.

I guess CME would work over time, but I'd be afraid of it crashing
and/or a ton of upgrades timing out and failing and starting over and
taking longer.

Frazee, Timothy wrote:
> What about setting up CME at the remote site voice router and put the
> firmware files on it? Run CME till the phones are up to the right rev
> then switch 'em to CUCM.
> 
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Jason Roysdon
> Sent: Friday, November 07, 2008 1:14 PM
> To: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] Peer Firmware Sharing
> 
> 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
>>
>>
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
> 
> This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
>