[cisco-voip] Peer Firmware Sharing

[Frazee, Timothy]

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.