IP forwarding is a little-used feature of most UNIX TCP/IP stacks. It allows the stack to act as a router, which can either be a very useful feature or a systems administrator's nightmare. On the useful side, IP forwarding allows a small, specialized network to be connected to a larger network without the need to purchase an expensive router, just another NIC card. On the nightmare side, it can generate a large number of extra packets on the network, possibly all addressed to a router. This article examines the latter scenario, what causes the problem, and how to avoid it.
When IP forwarding is "on", a system will attempt to forward any packet received at the data link layer that is not addressed to it at the IP layer. There are two ways that this can happen. First, a data link frame can be explicitly addressed to the system at the data link layer but not at the IP layer. This is exactly the case for a router (or for a system acting as a router) and is probably not a problem. Second, the data link destination can be the broadcast address, but the system does not recognize the IP destination as the broadcast address. This can be caused by the data link layer carrying more than one IP network or subnetwork, a system on the network having the wrong subnet mask, or the target system having the wrong subnet mask.
Regardless of the cause, the result is the same. When an application sends out an IP broadcast, the data link layer MAC address is set to broadcast so that all systems on the LAN will receive and process it. Since the IP address is not recognized as the broadcast address, the system will attempt to forward the packet. How it tries to do this will depend on the IP address.
For simplicity, let's define three systems. The source system is the system that sent the original packet. The destination system is the system intended to receive the original packet. In the case of a broadcast, there will be more than one target system. The forwarding system is a system with IP forwarding turned on, which is forwarding (or trying to forward) the original packet.
If the data link layer is carrying two networks or subnetworks, then the IP broadcast address for network/subnetwork 1 will not be recognized as the IP broadcast address by the forwarding system if it is on network/subnetwork 2. The forwarding system will consult its routing table, and if a route is found to network/subnetwork 1, it will forward the packet to the appropriate router. Note that if a default route is defined, and no other route to the destination is found, the default route will be used. The result is that the packet will probably be received twice by the target systems - once from the original transmission and once from the forwarded transmission. Additionally, if the router is on the same data link layer as the source, then each packet will appear three times on the data link layer (original transmission, from the forwarding system to the router, and from the router to the destination).
What if there's only one network but a subnet mask mismatch? If the subnet mask of the forwarding system is more restrictive than the subnet mask of the source system, then the forwarding system will think the broadcast address is just on a different subnet. For example:
Address 22.214.171.124 126.96.36.199
Subnet mask 255.255.255.0 255.255.255.240
Subnet 198.168.10 188.8.131.52
Broadcast 184.108.40.206 220.127.116.11
The effects are exactly the same as having two different networks or subnetworks on the same data link layer. The forwarding system will look up 18.104.22.168 in its routing table and route accordingly. Note that it is possible to get lucky. With the following addresses and masks, both the source and forwarding system have the same IP broadcast address; so the forwarding system will not forward anything even though the subnet masks don't match.
Address 22.214.171.124 126.96.36.199
Subnet mask 255.255.255.240 255.255.255.192
Subnet 188.8.131.52 184.108.40.206
Broadcast 220.127.116.11 18.104.22.168
What if the forwarding system's subnet mask is less restrictive than the source system's?
Address 22.214.171.124 126.96.36.199
Subnet mask 255.255.255.240 255.255.255.0
Subnet 188.8.131.52 198.168.10
Broadcast 184.108.40.206 220.127.116.11
In this case, the forwarding system thinks that the destination IP broadcast address is just a system on the local subnet. It will therefore broadcast an address resolution protocol (ARP) packet to obtain the MAC address of the system. If the source system's understanding of the subnet mask is correct, there will be no system with that IP address. The forwarding system will broadcast several ARP packets and, after receiving no reply, will discard the packet. However, until then, the forwarding system will have some network buffers tied up. There is some network bandwidth wasted on the ARP packets.
If the forwarding system's understanding of the subnet mask is correct, it's possible that the IP broadcast address used by the source system is really used by a system on the network. In that case, the system will get the packet twice - once from the broadcast and once from the forwarding system.
The simplest way to tell if this is happening to your system and network is with netstat. The IP statistics include a counter of the number of packets forwarded. If the number is non-zero and the system is not supposed to be acting as a router, then there is a problem. Keep in mind, however, that the statistics reported by netstat are from the system boot time, so it's possible that the problem has been fixed. If you have a network analyzer, you will also be able to see the extra packets on the network. Seeing a system send an ARP request for what you believe is a broadcast IP address is a pretty good sign that the system has IP forwarding on and that it has an incorrect subnet mask.
The final issue concerns what to do about the problem. The obvious answer is to make sure that all systems sharing the same data link are on the same network and have the same subnet mask. Unfortunately, that might not always be possible. If not, then you must turn off IP forwarding (or live with the consequences). How you do this depends on your operating system. On SVR4 UNIX systems, you can use the crash utility to set the ipforwarding global variable to 0 (a value of 1 allows forwarding). On HP-UX systems, you can use the nettune utility to set the ip_forwarding value to 0.
The nettune -h ip_forwarding will display an explanation of the variable. The -s control argument can be used to set the value. In the following case, it starts off as 1 (forwarding enabled) and is changed to 0 (forwarding disabled). You do not have to be logged in as root to display help and look at the values, but you do have to be root to set a value.
# nettune -h ip_forwarding
When enabled, an attempt will be made to forward received packets not destined for the
local machine along an appropriate route.
When disabled(0), not attempt will be made to forward any packet.
# nettune ip_forwarding
# nettune -s ip_forwarding 0
# nettune ip_forwarding
In crash, you use the w4 command to write 4 bytes of data and the od command to display the data. In the following example, ipforwarding is first displayed and has a value of 1. It's then set to 0 and redisplayed just to make sure. As with HP-UX, you do not have to be root to use crash and display values, but you must be root to write them.
System: pandora (Continuum Model 425) serial #273
dumpfile = /dev/mem, namelist = /unix, outfile = stdout
C0> od ipforwarding
043623b0: 00000001 ....
C0> w4 ipforwarding 0
C0> od ipforwarding
043623b0: 00000000 ....
From the Windows NT control panel, select network and then the Protocols tab in the network dialog.. Highlight TCP/IP Protocol and press the Properties button. Once the Properties dialog is displayed, select the Routing tab. You can see the Enable IP Forwarding check box.
Windows 95 does not support IP forwarding, but in Windows NT, the Routing dialog contains a check box to turn IP forwarding on and off. You get to the routing dialog via the configuration panel by selecting Network, Protocols, TCP/IP, and Routing. The change will require that you reboot the NT system.
About the Author
Noah Davids works in the Customer Assistance Center of Stratus Computer Inc. He specializes in the diagnosis and correction of LAN problems. "It's the wire" followed by "it's the router" covers most problems. The trick is finding which wire or router. He can be reached at Noah_Davids@stratus.com.