Redirecting Future Transmissions to an Alternate Router
ICMP (Internet Control Message Protocol) has a variety of commands and replies that are used to inform devices of routing related information. One common ICMP command is the ECHO Command and ECHO Reply used by the PING command to determine that a remote station is present. ICMP can request the value of a station's address mask and it can inform a sender that a destination is unreachable.
At this point in our discussion we are going to focus on the form of the ICMP command called a REDIRECT. An ICMP Redirect Command is used to inform a sender that the IP destination to which a frame was sent is not the right one and to tell the sender where to send frames in the future.
Consider a situation where a number of end-nodes on a single Ethernet segment or single Token-Ring have access to only one router. The Default Gateway parameter in all the stations is set to the IP address of the router. Any frame not destined for the local segment/ ring is simply sent to the only available router which then forwards it on the ultimate destination network.
If this simple network design is expanded so that two routers are attached to the same network as a particular end-node a different situation occurs. Let's consider a network 188.8.131.52 which is masked as 255.255.0.0. If end-node 184.108.40.206 wants to send a frame to 220.127.116.11 then it broadcasts an ARP frame and sends the frame directly. If 18.104.22.168 wants to send a frame to 22.214.171.124 then it looks in its routing table to see if a route exists. In this example assume that 126.96.36.199 was just turned on and the routing table is empty except for the Default Gateway which we will say is 188.8.131.52, a router on the cable segment. Hence, our end-node will ARP for the data link address of the Default Gateway and forward the frame to that data link destination (to the Default Gateway). Now expand the example to assume that in addition to the Default Gateway there is a second router on the segment. Let's consider what happens when our end-node wants to send a frame to a remote destination that can only be reached by going through this other router. Let's call this other router 184.108.40.206.
The end-node now wants to send a frame to remote destination 220.127.116.11 which can only be reached through router 18.104.22.168, the other (non-Default Gateway) router on the segment. The end-node follows the exact logic as before; the frame is sent to the Default Gateway (22.214.171.124). This time, however, the Default Gateway realizes that the other router (126.96.36.199) is the correct router for forwarding of the frame. Two actions occur: 1) The Default Gateway sends an ICMP Redirect message back to the originating end-node telling it to redirect to 188.8.131.52 and 2) the Default Gateway politely forwards the original frame over to 184.108.40.206 precluding the need to have it retransmitted by the end-node.
Let's summarize this behavior: When the Default Gateway receives a frame that should actually be routed to an IP address other than the Default Gateway then the Default Gateway informs the originator using an ICMP Redirect message. The Redirect, in this case, would tell 220.127.116.11 that when sending frames to network 18.104.22.168 that they should be sent to router 22.214.171.124. The end-node will have to ARP in the normal manner to determine the data link address of 126.96.36.199 but, from then on, frames for 188.8.131.52 will be sent to the other router and not to the Default Gateway.
From the perspective of the ARP Cache and the Routing Table, the effect of an ICMP Redirect is as follows. Initially the routing table only contains the association for the Default Gateway. Assume that 184.108.40.206 is the address of the Default Gateway for a workstation. The Routing Table would say that 0.0.0.0 = 220.127.116.11 (where 0.0.0.0 is the indicator that means 'the default gateway'). The ARP Cache would initially be empty.
When the station boots up, it ARP's for the data link address of the Default Gateway. The ARP reply returns this data link address which we will call MAC#1 (using the '.1' from the IP address to associate the two in this text). The MAC (or 'data link') address is the physical, hardware address of the network interface card.
When this station receives a redirect for 18.104.22.168 to router 22.214.171.124 it causes the Routing Table to be updated to reflect the following:
0.0.0.0 = 126.96.36.199
188.8.131.52 = 184.108.40.206
The next time a frame is destined to network 220.127.116.11 the Routing Table returns 18.104.22.168 as the correct 'next hop' to the destination. But, the workstation can not yet send frames to that 'next hop' until it resolves the data link address for 22.214.171.124. It will ARP now for 126.96.36.199 and the ARP Cache will contain:
188.8.131.52 = MAC#1
184.108.40.206 = MAC#201
This behavior continues as the station interacts in the network. While unused entries in the ARP Cache may age-out after a few seconds, the Routing Table may age-out after 20 minutes or so if the route remains unused.
Multiple Subnets On The Same Segment or Ring
As you read the following section, you MUST be aware that in 1995 a new set of RFC's were established to define the issue of multiple subnets on the same segment or ring. Essentially, they define a set of device behaviors that are considered, today, to be more appropriate that the ones described in this section. So, we can think through the issues described in this first section, titled "The Way It Was", and then read on to the new RFC descriptions in the section titled "The Way It Is Today".
In an ideal world a single port on a router is configured and connected to a cable on which stations are all configured with the same address mask. This implies that they are all on the same network and sub network (since the masked bits which define the 'locator' portion of the address would be configured to be identical on all stations). This would make life easy for the router. One port would equal one IP net work/ sub network and all stations would be so configured.
It is not, however, an ideal world. It is possible (probable?) that the stations on a segment are configured with different net work/ sub network locators. A segment, in this context, refers to not only a single Ethernet segment or Token-Ring but to a group of physical segments or rings interconnected with repeaters, bridges, or switches. In a very loose sense one could conceive of a network which was configured at random or one that resembled a random configuration. Alternatively, consider a situation where a router has 12 ports, each port configured as a separate IP subnet. This router is replaced with a switch. When a station on the Port #1 segment wants to talk to a station on a Port #5 segment it perceives the destination address as being remote (since the IP addressing and masking were not changed from when the segments were attached to the router). The sender addresses the frame to the data link address of the new Default Gateway (which is, for sake of discussion, attached to the segment on Port #2). The Default Gateway uses a Redirect to inform the originator that the destination is directly reachable. Consider the result of the update to the routing table when 220.127.116.11 now wants to contact 18.104.22.168.
0.0.0.0 = 22.214.171.124
126.96.36.199 = 188.8.131.52
Does this appear strange? The Redirect message said that frames being sent to 184.108.40.206 should be 'redirected' to 220.127.116.11; the same IP destination address. Let's see how this will make the workstation behave when the next frame is to be sent to 18.104.22.168.
22.214.171.124 still thinks the destination is remote. The routing table is consulted to see if 126.96.36.199 (the host-specific route) or 188.8.131.52 (the network route) is in present. This time the destination is found (and is perceived as a host-specific route). 184.108.40.206 understands from the routing table that frames addressed to 220.127.116.11 should be sent to IP destination 18.104.22.168 and so an ARP frame is used to resolve the address 22.214.171.124. Since 126.96.36.199 is actually directly reachable (through the switch) it responds to the ARP and the MAC#123 address (the data link address of 188.8.131.52) is added to the ARP Cache. The frame is now forwarded directly to the destination machine.
If the sending machine were conscious and self-aware it would think that it was forwarding the frame to the data link address of a router. In fact, the Redirect has 'tricked' the process into sending to a directly reachable data link destination which is actually that of a destination configured on a different subnet (but physically in the same real location. Multiple subnets are configured on the same logical segment and the ICMP Redirect is used to 'trick' the senders into using the true data link destination.
The previous section, "The Way It Was" describes a subnet scenario that violates RFC 1122 and RFC 1812.
RFC 1812 section 184.108.40.206 says:
A Redirect message SHOULD be silently discarded if the new gateway address it specifies is not on the same connected (sub-) net through which the Redirect arrived [INTRO:2, Appendix A], or if the source of the Redirect is not the current first-hop gateway for the specified destination (see Section 3.3.1)
This means that hosts should ignore the redirects described in the "The Way It Was" section.
RFC 1812 section 220.127.116.11 says:
Routers MUST NOT generate a Redirect Message unless all the following conditions are met:
- The packet is being forwarded out the same physical interface from which is was received.
- The IP source address in the packet is on the same Logical IP (sub)network as the next-hop IP address, and
- The packet does not contain an IP source route option.
Low-End IP Stacks That Don't Support Redirects
Not every IP implementation (particularly on some lower-performance devices) support the full range of ICMP functionality. While it can be assumed that all IP communicators support ICMP Echo and Echo Reply (for the Ping command) they don't all support the Redirect functionality. In this case a redirect to an alternative router or directly to a local destination configured on a different subnet would not be redirected. The originating station would continue to send the frames to the router. The router would continue to send Redirects and then forward the frames to the destination. The conversation would work but would require the additional traffic associated not only with the Redirect frames but with the double copy of the original frame (once from originator to router and the second time from the router to the destination). The traffic load on the network would go up unnecessarily and the performance would degrade due to loading and due to the additional propagation delay through the router for each frame.
To compensate for this deficit in some IP stacks router vendors may offer configuration parameters that allow the number of Redirects sent to a station with no effect to be limited. A Cisco router, for example, allows a maximum of 15 redirect frames to a station before it stops sending redirects to that station. The router will still forward the incoming frames to the correct destination but at least the unnecessary, ignored ICMP frames are eliminated. This intelligent option in a router doesn't fix the problem (because the workstation doesn't support redirects) but at least it helps prevent the bad situation from becoming even worse (because the unheeded ICMP Redirect frames are shut off).
The real 'fix' (ok... the real fix is to get an IP stack that supports redirects; but..) is to turn on Proxy ARP at the workstation and the router. By default, most routers have Proxy ARP active. Some workstations may not support Proxy ARP. With Proxy ARP working the whole ICMP issue is circumvented. All stations ARP for all destinations.
Problems With Address Masking
When a station is configured with an incorrect address mask the effect is to confuse it as to whether a destination is remote or local. Because this incorrectly configured station doesn't perform the correct masking of a destination address the whereabouts of the destination is judged incorrectly. If a remote destination is perceived to be local then the sender ARP's and the ARP fails. If a local destination is perceived to be remote then the sender forwards to the Default Gateway with the associated Redirect and (hopefully) adjustment of the routing table. These inappropriate behaviors can be observed with a protocol analyzer.
When Proxy ARP is active in the router there is the effect that the misconfigured address mask values in the workstations are concealed. The station that thinks a remote destination is actually local will ARP incorrectly for the remote destination. The router will simply answer the ARP (the 'proxy' response).
The concern with Proxy ARP is that is can conceal a number of misconfigured address masks on the network. Now, this is fine as long as you are willing to accept the network as a misconfigured mess being held together by the Proxy feature in the router. When the day comes to reconfigure the network (tomorrow?) you have a world of problems waiting for you. The inconsistent masking that was being concealed by the Proxy feature in the router comes back to haunt you at the worst possible times (...ten minutes to five on Friday afternoon as you are getting ready to leave for a three-day weekend!).
As an experiment, try turning Proxy ARP off in your routers. Don't do this if 1) your design calls for no-default-gateway / Proxy-ARP-ON in the
workstations or 2) you are running an important application on the network. Be careful. Turning Proxy ARP off may cause catastrophic problems. That's the
idea. If your network design doesn't call for Proxy ARP to be on then the network should work properly when you turn it off. Try it experimentally to see
if you get problems. If you do then you can solve them in a controlled manner rather than waiting for the worst possible time for these ugly monsters to rear