[cisco-voip] Peer Firmware Sharing

[Steve G]

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> 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
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20081106/7083b218/attachment.html>