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 18.104.22.168 which is masked as 255.255.0.0. If end-node 22.214.171.124 wants to send a frame to 126.96.36.199 then it broadcasts an ARP frame and sends the frame directly. If 188.8.131.52 wants to send a frame to 184.108.40.206 then it looks in its routing table to see if a route exists. In this example assume that 220.127.116.11 was just turned on and the routing table is empty except for the Default Gateway which we will say is 18.104.22.168, 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 22.214.171.124.
The end-node now wants to send a frame to remote destination 126.96.36.199 which can only be reached through router 188.8.131.52, 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 (184.108.40.206). This time, however, the Default Gateway realizes that the other router (220.127.116.11) 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 18.104.22.168 and 2) the Default Gateway politely forwards the original frame over to 22.214.171.124 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 126.96.36.199 that when sending frames to network 188.8.131.52 that they should be sent to router 184.108.40.206. The end-node will have to ARP in the normal manner to determine the data link address of 220.127.116.11 but, from then on, frames for 18.104.22.168 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 22.214.171.124 is the address of the Default Gateway for a workstation. The Routing Table would say that 0.0.0.0 = 126.96.36.199 (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 188.8.131.52 to router 184.108.40.206 it causes the Routing Table to be updated to reflect the following:
0.0.0.0 = 220.127.116.11
18.104.22.168 = 22.214.171.124
The next time a frame is destined to network 126.96.36.199 the Routing Table returns 188.8.131.52 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 184.108.40.206. It will ARP now for 220.127.116.11 and the ARP Cache will contain:
18.104.22.168 = MAC#1
22.214.171.124 = 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 126.96.36.199 now wants to contact 188.8.131.52.
0.0.0.0 = 184.108.40.206
220.127.116.11 = 18.104.22.168
Does this appear strange? The Redirect message said that frames being sent to 22.214.171.124 should be 'redirected' to 126.96.36.199; the same IP destination address. Let's see how this will make the workstation behave when the next frame is to be sent to 188.8.131.52.
184.108.40.206 still thinks the destination is remote. The routing table is consulted to see if 220.127.116.11 (the host-specific route) or 18.104.22.168 (the network route) is in present. This time the destination is found (and is perceived as a host-specific route). 22.214.171.124 understands from the routing table that frames addressed to 126.96.36.199 should be sent to IP destination 188.8.131.52 and so an ARP frame is used to resolve the address 184.108.40.206. Since 220.127.116.11 is actually directly reachable (through the switch) it responds to the ARP and the MAC#123 address (the data link address of 18.104.22.168) 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 22.214.171.124 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 126.96.36.199 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