Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations biv343 on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ISS TFTP Connections

Status
Not open for further replies.

Devolution

Programmer
Jun 6, 2005
189
GB
I was wondering how many concurrent TFTP connections the ISS could handle?

We are replacing an MXe Server (MCD5 SP2 PR1) handling approx 2500 IP phones with a slightly higher MCD version ISS (MCD5 SP2 PR2) and the phones will have to download the new firmware. It is a 24/7 company and I am trying to estimate the time it will take for the phones to reboot.

I have read every doc for ISS and hopefully not missed the information. Wondered if anyone knew?

Thanks.
 
Engineering Guidelines has this for 3300 , I assume that the ISS has same limits

3300 TFTP server
The 3300 ICP internal TFTP server is used to provide the IP phones with application software.
This section provides information about the interaction that takes place between the IP phones
and the 3300 TFTP server.
The 3300 TFTP server can handle 400 sessions (this is configurable) simultaneously. If a
particular phone can’t get access to the TFTP server, it will try repeatedly for a number of
seconds, after which it will re-boot and start again.
Some time-out values of interest are:
• Phones will attempt to access the TFTP server three times before rebooting. Attempts to
access the TFTP server will be made at intervals of 15-30 seconds. This interval is random
to even out the loading on the TFTP server, and to avoid a situation where multiple sets
are attempting to access the TFTP server simultaneously.
• Inter-packet timeout can be up to four seconds. More reliable transmissions will cause the
inter-packet time to lessen and the transmission of acknowledgement packets and any
retries that might occur will speed up.
• Phones will attempt to complete the TFTP download in 20 minutes.
When a phone is setting up a TFTP session with the 3300 ICP's internal TFTP server or an
external TFTP server there is an "auto-negotiation" process that they go through to establish
the block size.
The devices will try to establish the block transfer size at 4096 bytes, then they try 2048 bytes,
then they try 1024 bytes and finally they try 512 bytes.
Block size is not user configurable on either the 3300 or the phone, however TFTP block size
could be user configurable on some 3'rd party external TFTP servers.
In situations where phones are accessing an external TFTP server over a very slow connection
reduce, if possible, the transmitted block size from 4096 to a smaller number; 512 or 1024. This
will increase the number of ack/nack messages, but will ensure that the four second inter-packet
timer is less likely to be exceeded, especially when multiple phones share the same restricted
link.
For best performance the TFTP server should be connected to the network with a minimum
bandwidth of 100Mbits/s. Lower bandwidth will reduce the throughput and result in increased
delays to bring the phones into service.
For a WAN link, the minimum bandwidth to ensure timely startup with minimum retries at the
phone is 15 kbits/s per phone. Higher bandwidths will result in phones returning to service
quicker, and a practical value to consider might be 100kbits/s/phone. Less available bandwidth
may result in phones retrying to complete the download and hence take additional time.
Engineering Guidelines
252
Depending on the total number of phones that require access to the common TFTP server and
the time to have these in service the following WAN minimum bandwidths per phone are
recommended:

Total number of phones on TFTP server - Recommended Minimum WAN bandwidth per phone
500 -20kbits/s
1000 -35kbits/s
1500 -50kbits/s
2000 -70kbits/s
2500 -85kbits/s
3000 -100kbits/s
3500 -120kbits/s
4000 -135kbits/s
4500 -150kbits/s
5000 -170kbits/s
Although lower bandwidths may be used, this may result in a number of phones failing to
complete the download in the expected time, resulting in subsequent retries and time to come
into service.

If I never did anything I'd never done before , I'd never do anything.....
 
Thanks Billz66, I had seen that but still wondered if the ISS had better stats? I will work with this information and if it turns out to be quicker on the night, I'll consider it a bonus and claim it was my preparation and skill that saved the day.
 
Do you have the option of using an external TFTP server instead? Change the setting in DHCP, load your sets, and the new DHCP settings will send your phones to the other TFTP server.

As far as how long, I just did 1600 sets over the weekend and loading 300 sets at a time (all 5212's and 5224's, mind you), it took less than 15 minutes from the first "load" command until I saw the last set re-register with the MXE Server. The customer had a couple of mission-critical 24/7 areas, so for those we had multiple sets set up ahead of the upgrade and just manually rebooted those as they were available.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top