Digital Elephant
Network Testing
Recent Linux distributions have begun supplying firewall protection by default. This is a fine idea if the system installed is a boundary machine (has an interface connected to the Internet), but it can get in the way on machines that are connected only to the private network. To check if there is a set of firewall rules defined, look at the result of this command:
[root@foo]# iptables -nvL
If the rule listing indicates that the default policy is DENY, or if there are rules that have a target of DROP or REJECT, then you have a firewall configuration in place. This is not necessarily bad, but it must be kept in mind when conducting the tests below. If a test fails, firewall rules could be blocking either the outbound network traffic, or the replies.
Once any problems with system initialization are cleared up, the next step is to test the network setup for proper operation. It is best to begin at the lowest level: basic packet exchange between the Linux box and its nearest neighbor(s). The utility to check this is ping. For each interface, decide on a target machine that is physically attached to the same network segment, and send a ping towards that address. For example, if the Linux box is attached to a private ethernet, and its address is 192.168.1.1,
[root@foo]# ping 192.168.1.4
would try to exchange packets on the private ethernet segment with another machine whose address is 192.168.1.4. Some operating systems may be configured to ignore these pings, so it is a good idea to make sure that the intended target machine will not ignore you. A target Windows XP system may be examined using the excellent procedure found here. You can examine a target Linux system's setting with the command
[root@foo]# cat /proc/sys/net/ipv4/icmp_echo_ignore_all
This command should print 0; if it prints 1, the machine will ignore ICMP packets, and will not make a very satisfactory test target.
If all goes well, you should see a sequence of messages like this:
[root@foo]# ping 192.168.1.4 PING 192.168.1.4 (192.168.1.4) from 192.168.1.1 : 56(84) bytes of data. 64 bytes from 192.168.1.4: icmp_seq=0 ttl=32 time=382 usec 64 bytes from 192.168.1.4: icmp_seq=1 ttl=32 time=366 usec 64 bytes from 192.168.1.4: icmp_seq=2 ttl=32 time=359 usec 64 bytes from 192.168.1.4: icmp_seq=3 ttl=32 time=363 usec 64 bytes from 192.168.1.4: icmp_seq=4 ttl=32 time=335 usec 64 bytes from 192.168.1.4: icmp_seq=5 ttl=32 time=303 usec
Terminate the process by typing control-C; then you will get this report:
--- 192.168.1.4 ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.303/0.351/0.382/0.029 ms [root@foo]#
This test should be conducted for each interface on the Linux box. For any connection that involves dial-up, you will probably need to make that connection before running this test. Other problems generally cause a timeout to occur. There are lots of things that can contribute here; the most common are disagreement between netmasks at the sender and the receiver, and incorrect routes that send the ICMP Echo packet out on the wrong interface. Both of these can be diagnosed by using the tcpdump utility, which displays messages for each packet that passes through the given interface. See the manpage for this utility if you need this diagnostic.
Once we know that the Linux box can talk to neighbors on each of its attached segments, it is time to check whether packets are correctly forwarded through the box. The first thing to check is whether IP forwarding is enabled:
[root@foo]# cat /proc/sys/net/ipv4/ip_forward 1 [root@foo]#
This variable is set up by the script /etc/rc.d/init.d/network, based on the value of the parameter FORWARD_IPV4 in /etc/sysconfig/network. If /proc/sys/net/ipv4/ip_forward has the value 0, either the parameter is incorrectly specified in /etc/sysconfig/network, or the network initialization script did not run correctly. The system log file should shed light on the latter situation.
Finally, we can actually try to forward traffic through the Linux box. The ping utility is again a good tool for this purpose, but this time, it should be run on another machine on one side of the Linux box, and the target should be a machine on the other side. This test should precede the installation of firewall configuration, so that firewall restrictions do not confuse the result. Windows boxes have the ping utility available from a command-line prompt, and can be used as a source for this test.