Take the 2-minute tour ×
Network Engineering Stack Exchange is a question and answer site for network engineers. It's 100% free, no registration required.

It seems like a strange idea to transfer files using a connectionless protocol - so in what situation would you not care about if the entire file is delivered or not? I read somewhere that TFTP is used for upgrading the firmware of routers, but why would you do that with TFTP? Wouldn't that mean that you can't be sure that all the data (the entire update) has arrived at the destination?

share|improve this question

2 Answers 2

It seems like a strange idea to transfer files using a connectionless protocol - so in what situation would you not care about if the entire file is delivered or not?

I'm going to add a bit to YLearn's excellent answer... You always want the entire file delivered. Asserting that one doesn't want the whole file transferred because of TFTP is a faulty understanding of TFTP.

I read somewhere that TFTP is used for upgrading the firmware of routers, but why would you do that with TFTP?

It is a very simple, but still reliable protocol. There are times you may get stuck at the Cisco IOS rommon prompt (either for debugging, or because of an error). Rommon is a tiny environment itself; rommon images are typically around 500KB. Sometimes you wind up transferring files from within rommon; thus you need a small file transfer protocol like TFTP if you want the protocol to fit inside rommon. By using tftp, rommon can use a much smaller IP stack (UDP and IP, without TCP).

I read somewhere that TFTP is used for upgrading the firmware of routers, but why would you do that with TFTP?

No authentication is primarily the reason I do it; it is less typing and a very easy way to transfer images. You certainly can use scp or ftp. There is no reason to bother with that... so what if someone sniffs my IOS image?

Wouldn't that mean that you can't be sure that all the data (the entire update) has arrived at the destination?

This is an incorrect understanding of TFTP. TFTP is a reliable transfer protocol, by default each tftp packet must be acknowledged, which means it's slower, especially over a WAN (because there are no TCP windowing dynamics).

Once the image is on the router, you should always verify the IOS checksums against those posted on Cisco's website...

S01#verify /md5 flash:c3560-ipservicesk9-mz.122-58.SE2.bin
........................................................................................
........................................................................................
...........................................................
verify /md5 (flash:c3560-ipservicesk9-mz.122-58.SE2.bin) = bbddf83e7ee1023619630110b6b3a998

S01#
share|improve this answer
    
FYI, a link to discussion in chat –  Mike Pennington Mar 1 at 20:37

TFTP uses UDP for the transfer, which as you indicate is a connectionless protocol. FTP, SCP, HTTP or other methods of transfer typically use TCP.

UDP requires less overhead and is generally faster than TCP. There is no TCP acknowledgements nor the TCP window to account for during the transfer.

There are generally other methods to verify the data once it has arrived, typically by comparing a calculated hash to a known value. Since the transfer typically takes place over your own network under your control, which hopefully is reliable, they generally turn out fine.

Also, many devices will allow you to set a primary and a backup image to boot from, so you can configure the device to boot from the backup if the primary image fails to load for some reason.

If you are using an unreliable network, another option is typically available to use such as FTP. However you will still probably want to use any verification methods you have available to ensure data integrity.

share|improve this answer
    
Okay, so the "completeness" (is there a better word for it?) of the arrived data can only be checked manually by comparing two hashes like Mike Pennington showed? @Ylearn –  Axel Kennedal - TechTutor Mar 3 at 11:51
1  
No. It's actually handled in TFTP protocol itself. Basically TFTP data transfer is done in 512 bytes packets, sender numbers these and for every packet receiver sends an ack back to sender. If no ack is received, data is retransmitted. So, in terms of reliability it's as reliable as TCP. The main point using TFTP nowadays is a simplicity. You can implement with very small amount of code. Besides routers and switches think about network boot etc. –  Thom Mar 3 at 13:01
1  
@AxelKennedal-TechTutor, as has been pointed out, the TFTP application handles the error correction and retransmission rather than relying on the lower layers. However whether you use TFTP or any other protocol, you should always verify your file. Most often this does use some sort of hash (often MD5) comparison but depending on vendor/platform, this can take several forms with varying levels of assurance. As to how automatic/manual this verification is, this also varies. As Mike's example, you can run a verify without the hash, or use the MD5 hash for higher assurance. –  YLearn Mar 3 at 13:16
    
@YLearn Okay, got it! So all of this happens at the OSI application layer? –  Axel Kennedal - TechTutor Mar 3 at 13:49
1  
@AxelKennedal-TechTutor, for the TCP/IP model, it would definitely be the application layer. For OSI, I couldn't say with any certainty which layer it would fall into, but I would venture to say it is at the application layer as well. –  YLearn Mar 4 at 3:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.