[cisco-voip] CCM DevPack and SR Interactions

[Wes Sisk]

Hi Matthew,
inline..
/Wes

Matthew Melbourne wrote:
> I'm considering an upgrade to CCM 4.1(3)SR6. However, this has not yet
> appeared on the compatibility matrix with CRS 4.0(5).
>
> In order to add device support for the 7921s, it is necessary to apply a
> DevPack. I was hoping to do this with the application of SR6 which itself
> includes DevPack 64. 
>
> If I apply the standalone DevPack 65 (which is compatible with the
> existing CCM 4.1(3)SR2, will the later application of SR6 overwrite the
> device loads set by DevPack 65?
>   
ws: yes, the later installation will overwrite settings in the 
database.  i.e. SR6 will overwrite settings by devpack65.  However, 
generally this is VERY discouraged.  There may not be anything in the 
installer to prevent it, but generally installing and older version on 
top of a newer version is very bad idea.
> Obviously, when device loads get updated there is the possibility that a
> large number of phones will attempt to update at the same time. What is
> the robustness of this procedure (assuming one TFTP server on the
> Publisher)? Is it advisable to reload phones in a controlled manner,
> perhaps on a site-by-site basis by bouncing switch ports?
>
>   
ws: A very good question.  For 2nd gen phones resetting phones in 
batches of 200-500 usually produces successful upgrade.  For 3rd gen 
phones 7970,71,41,61 keep to batches of 200 as the loads are much larger 
and take much more time to transfer via TFTP.  These are rough numbers 
that are heavily dependent on your number of TFTP servers, tftp traffic 
distribution, bandwidth available between phones and TFTP server, and 
TFTP server configuration, phone models, and phone configuration.  The 
primary limiting factors:
1. older CM versions had a limited number of TFTP threads available to 
respond to TFTP requests.  Newer versions of CM have many more threads 
and are configurable with a service parameter for truly dedicated TFTP 
servers.
2. 2nd gen phones, i.e. 7910/40/60 phone loads are very small and 
transfer relatively quickly over the 512 byte blocks required for TFTP.  
3rd gen phones, i.e. 7941, 61,70,71 have very large loads (10+MB) so 
transfer very slowly over 512 byte blocks required for TFTP.
3. the limiting factor for TFTP is usually round trip time. each 512byte 
block has to be individually acknowledged before the next 512 byte block 
can transmit.  Any packet loss dramatically affects this.  High round 
trip time dramatically affects this.
4. newest versions of CM and phone loads support peer to peer firmware 
sharing which dramatically reduces tftp load so long as the feature is 
functional in your network L2 environment.
5. 3rd gen phones have 2 rather nasty issues that directly affect this:
a. older loads have a bultin TFTP timeout: CSCsb10954
b. if 3rd gen phone detects 'load corruption' it will not use the 'load 
server'.  Usually load server is used exactly to address the issue of 
high round trip time to TFTP server.  load server indicates a local TFTP 
server where the phone can retrieve the large load files.

> Cheers,
>
> Matt
>
>