[cisco-voip] Remote Site TFTP Woes

[STEVEN CASPER]

Regarding Peer Firmware Sharing I am wary of this bug  - CSCtg96408 Third-gen phone (7911/41, etc) fails to boot after PFS upgrade. 
 
Looks like it was recently fixed on the latest versions of  SCCP 9.1.1
 
Steve


>>> Wes Sisk <wsisk at cisco.com> 11/18/2010 5:02 PM >>>
Engineer's favorite answer: it depends.

* TFTP is especially inefficient over WAN. See:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/netstruc.html#wpmkr1185039 

* This is all exacerbated in very old phone loads with hard coded 
timeouts. Examples:
7937 stops downloading load via TFTP after one hour , Fixed CSCso55333
load update process to kill CVM before loading, rm 10 min TFTP timeout , 
Fixed CSCsb10954

* This is further exacerbated by increased load size in 'newer phones' 
such as 7970,79x1, 79x2, 79x5

* Fourth gen phones (89xx,99xx) get a bit of reprieve because (1) they 
download in the background while the phone is up and registered and (2) 
they get (are getting?) firmware download via HTTP.

* Oddly enough I often see this exacerbated by speed/duplex mismatch at 
the switch port of the TFTP server. Is the network healthy otherwise? No 
packet loss, asymmetric routing, etc.

Recommended actions:
1. Identify the model and load of phone in use.  If it fits into the 
'working but slow due to nature of TFTP' then contact your Cisco account 
team and press to have HTTP firmware download ported into those phone 
models.
2. In the mean time use either 'load server' or 'peer firmware sharing' 
for remote site phones:
Load server: 
http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7961g_7961g-ge_7941g_7941g-ge/firmware/7_0_2/english/release/notes/6141702.html#wp1029737 
Peer firmware sharing:
http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7961g_7961g-ge_7941g_7941g-ge/firmware/8_3_1/english/release/notes/61831.html#wp116015 

/Wes


Mike King wrote:
> We have a remote SRST site that we're bringing up.  We normally do a
> P2P link with a ping RTT of 3ms, but this site got rushed, and the P2P
> link is still on 120 to 180 day order.
>
> We bring the site up using Comcast Cable modem service(50down 20 up).
> RTT is around 30 ms.
>
> We use ASA to ASA IPSEC L2L tunnels
>
> When the phones register, the TFTP traffic for the firmware upgrade is
> dog slow.  To the point where the phones eventually stop downloading
> it.  (We packed all the phones up, and dragged them somewhere else to
> upgrade the firmware, that's not the issue)
>
> I fire a TFTP client up on my laptop, and a TFTP server at the same
> site as the callmanager, and transfer a 90MB file.  It takes around 2
> hours.  If I use windows file sharing, it takes about 4 minutes.
>
> I have a TAC case open with ASA Security / VPN.  I'm getting chatter
> that "tftp is a lock-step protocol that requires an ack to be sent and
> received for every data packet sent, before the next packet is sent"
> and with the RTT we have that is the maximum speed we should expect.
>
> So for the next time I have to upgrade the firmware on the phones at
> that site, what are your suggestions?
>
> The way I'm seeing it:
> 1.  Something is Broke, and TFTP shouldn't take that long.
> 2.  Yes, that's normal, you will have to do something different, like
> use a TFTP load server.
>
> So which is it?  Any opinion is welcome.
> _______________________________________________
> cisco-voip mailing list
> 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 email may contain privileged and/or confidential information that is intended solely for the use of the addressee.  If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission.  If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy.  This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act.  You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information.
There are risks associated with the use of electronic transmission.  The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission.
************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20101119/193ef087/attachment.html>