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!

Searchable, convenient, complete TCP/IP information.
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 Time Exceeded Messages
Previous Page
Pages in Current Topic/Section
1
23
Next Page
ICMPv4 Parameter Problem Messages
Next Topic/Section

ICMPv4 Redirect Messages
(Page 1 of 3)

Every device on an internetwork needs to be able to send to every other device. If hosts were responsible for determining the routes to each possible destination, each host would need to maintain an extensive set of routing information. Since there are so many hosts on an internetwork, this would be a very time-consuming and maintenance-intensive situation.

Instead, IP internetworks are designed around a fundamental design decision: routers are responsible for determining routes and maintaining routing information. Hosts only determine when they need a datagram routed, and then hand the datagram off to a local router to be sent where it needs to go. I discuss this in more detail in my overview of IP routing concepts.

Since most hosts do not maintain routing information, they must rely on routers to know about routes and where to send datagrams intended for different destinations. Typically, a host on an IP network will start out with a routing table that basically tells it to send everything not on the local network to a single default router, which will then figure out what to do with it. Obviously if there is only one router on the network, the host will use that as the default router for all non-local traffic. However, if there are two or more routers, sending all datagrams to just one router may not make sense. It is possible that a host could be manually configured to know which router to use for which destinations, but another mechanism in IP can allow a host to learn this automatically.

Consider a network N1 that contains a number of hosts (H1, H2, etc…) and two routers, R1 and R2. Host H1 has been configured to send all datagrams to R1, as its default router. Suppose it wants to send a datagram to a device on a different network (N2). However, N2 is most directly connected to N1 using R2 and not R1. The datagram will first be sent to R1. R1 will look in its routing table and see that datagrams for N2 need to be sent through R2. “But wait,” R1 says. “R2 is on the local network, and H1 is on the local network—so why am I needed as a middleman? H1 should just send datagrams for N2 directly to R2 and leave me out of it.

In this situation, R1 will send an ICMPv4 Redirect message back to H1, telling it that in the future it should send this type of datagram directly to R2. This is shown in Figure 143. R1 will of course also forward the datagram to R2 for delivery, since there is no reason to drop the datagram. Thus, despite usually being grouped along with true ICMP error messages, Redirect messages are really arguably not error messages at all; they represent a situation only where an inefficiency exists, not an outright error. (In fact, in ICMPv6 they have been reclassified.)


Figure 143: Host Redirection Using an ICMP Redirect Message

In this example H1 sends to R1 a datagram destined for network N2. However, R1 notices that R2 is on the same network and is a more direct route to N2. It forwards the datagram on to R2 but also sends an ICMP Redirect message back to H1 to tell it to use R2 next time.

 


Previous Topic/Section
ICMPv4 Time Exceeded Messages
Previous Page
Pages in Current Topic/Section
1
23
Next Page
ICMPv4 Parameter Problem 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.