Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide


NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

Read offline with no ads or diagram watermarks!
The TCP/IP Guide

Custom Search







Table Of Contents  The TCP/IP Guide
 9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)
      9  TCP/IP Internet Layer (OSI Network Layer) Protocols
           9  Internet Control Message Protocol (ICMP/ICMPv4 and ICMPv6)
                9  ICMP Message Types and Formats
                     9  ICMP Version 4 (ICMPv4) Error Message Types and Formats

Previous Topic/Section
ICMPv4 Source Quench Messages
Previous Page
Pages in Current Topic/Section
1
23
Next Page
ICMPv4 Redirect Messages
Next Topic/Section

ICMPv4 Time Exceeded Messages
(Page 1 of 3)

Large IP internetworks can have thousands of interconnected routers that pass datagrams between devices on various networks. In large internetworks, the topology of connections between routes can become complex, which makes routing more difficult. Routing protocols will normally allow routers to find the best routes between networks, but in some situations an inefficient route might be selected for a datagram.

In the worst case of inefficient routing, a router loop may occur. An example of this situation is where Router A thinks datagrams intended for network X should next go to Router B; Router B thinks they should go to Router C; and Router C thinks they need to go to Router A. (See the ICMPv6 TIme Exceeded Message description for an illustration of a router loop.)

If a loop like this occurred, datagrams for network X entering this part of the internet would circle forever, chewing up bandwidth and eventually leading to the network being unusable. As insurance against this occurrence, each IP datagram includes in its header a Time To Live (TTL) field. This field was originally intended to limit the maximum time (in seconds) that a datagram could be on the internetwork, but now limits the life of a datagram by limiting the number of times the datagram can be passed from one device to the next. The TTL is set to a value by the source that represents the maximum number of hops it wants for the datagram. Each router decrements the value; if it ever reaches zero the datagram is said to have expired and is discarded.

When a datagram is dropped due to expiration of the TTL field, the device that dropped the datagram will inform the source of this occurrence by sending it an ICMPv4 Time Exceeded message, as shown in Figure 141. Receipt of this message indicates to the original sending device that there is either a routing problem when sending to that particular destination, or that it set the TTL field value too low in the first place. As with all ICMP messages, the device receiving it must decide whether and how to respond to receipt of the message. For example, it may first try to re-send the datagram with a higher TTL value.


Figure 141: Expiration of an IP Datagram and Time Exceeded Message Generation

In this example, device A sends an IP datagram to device B that has a Time To Live (TTL) field value of only 4 (perhaps not realizing that B is 7 hops away). On the fourth hop the datagram reaches R4, which decrements its TTL field to zero and then drops it as expired. R4 then sends an ICMP Time Exceeded message back to A.

 


There is another “time expiration” situation where ICMP Time Exceeded messages are used. When an IP message is broken into fragments, the destination device is charged with reassembling them into the original message. One or more fragments may not make it to the destination, so to prevent the device from waiting forever, it sets a timer when the first fragment arrives. If this timer expires before the others are received, the device gives up on this message. The fragments are discarded, and a Time Exceeded message generated.


Previous Topic/Section
ICMPv4 Source Quench Messages
Previous Page
Pages in Current Topic/Section
1
23
Next Page
ICMPv4 Redirect Messages
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



Home - Table Of Contents - Contact Us

The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005

© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.