 |  |
Chapter 9. Testing Connectivity Protocols
This chapter and the next describe tools used to investigate protocol-specific behavior. In this chapter, I describe tools used to explore connectivity protocols, protocols that work at the network and transport levels to provide connectivity. Chapter 10, "Application-Level Tools" focuses on tools used in testing protocols at the application level.I begin with a description of packet generation tools. Custom packet generators, like hping and nemesis, will allow you to create custom packets to test protocols. Load generators, like MGEN, will let you flood your network with packets to see how your network responds to the additional traffic. We conclude with a brief discussion of network emulators and simulators.
Many of the tools described in this chapter and the next are not tools that you will need often, if ever. But should the need arise, you will want to know about them. Some of these tools are described quite briefly. My goal is to familiarize you with the tools rather than to provide a detailed introduction. Unless you have a specific need for one of these tools, you'll probably want to just skim these chapters initially. Should the need arise, you'll know the appropriate tool exists and can turn to the references for more information.
9.1. Packet Injection Tools
This first group of tools generates and injects packets into your network. Basically, there are two different purposes for generating packets, each with its own general approach and its own set of tools.First, to test software configuration and protocols, it may be necessary to control the content of individual fields within packets. For example, customized packets can be essential to test whether a firewall is performing correctly. They can also be used to investigate problems with specific protocols or to collect information such as path MTU. They are wonderful learning tools, but using them can be a lot of work and will require a very detailed knowledge of the relevant protocols.
The second reason for generating packets is to test performance. For this purpose, you typically generate a large number of packets to see how your network or devices on the network respond to the increased load. We have already done some of this. In Chapter 4, "Path Characteristics", we looked at tools that generated streams of packets to analyze link and path performance. Basically, any network benchmark will have a packet generator as a component. Typically, however, you won't have much control over this component. The tools described here give you much greater control over the number, size, and spacing of packets. Unlike custom packet generators, load generators typically won't provide much control over the contents of the packets.
These two uses are best thought of as extremes on a continuum rather than mutually exclusive categories. Some programs lie somewhere between these two extremes, providing a moderate degree of control over packet contents and the functionality to generate multiple packets. There is no one ideal tool, so you may want to become familiar with several, depending on your needs.
9.1.1. Custom Packets Generators
A number of different programs will construct custom packets for you. The utilities vary considerably in the amount of control you actually have. As all require a thorough understanding of the underlying protocols, none of these tools are particularly easy to use. All of the ones I am familiar with are command-line programs. This is really a plus since, if you find yourself using these programs heavily, you will want to call them from scripts.Two programs, hping and nemesis, are briefly described here. A number of additional tools are cited at the end of this section in case these utilities don't provide the exact functionality you want or aren't easily ported to your system. Of the two, hping is probably the better known, but nemesis has features that recommend it. Neither is perfect.
Generally, once you have the idea of how to use one of these tools, learning another is simply a matter of identifying the options of interest. Most custom packet generators have a reasonable set of defaults that you can start with. Depending on what you want to do, you select the appropriate options to change just what is necessary -- ideally as little as possible.
Custom packet tools have a mixed reputation. They are extremely powerful tools and, as such, can be abused. And some of their authors seem to take great pride in this potential. These are definitely tools that you should use with care. For some purposes, such as testing firewalls, they can be indispensable. Just make sure it is your firewall, and not someone else's, that you are testing.
9.1.1.1. hping
hping, or hping2 as it is sometimes called, was written by Salvatore Sanfilippo. The documentation is a little rough at times and suggests uses that are inappropriate. Nonetheless, it is a powerful, versatile program.When run with the default parameters, it looks a lot like ping and is useful for checking connectivity:
At first glance, the output looks almost identical to ping's. Actually, by default, hping does not send ICMP packets. It sends TCP packets to port 0. (You can change ports with the -p option.) Since this port is almost never used, most systems will reply with a RESET message. Consequently, hping will sometimes get responses from systems that block ping. On the other hand, it may trigger intrusion detection systems as well. If you want to mimic ping, you can use the -1 argument, which specifies ICMP. Or, if you prefer, you can use -2 to send UDP packets.lnx1# hping 205.153.63.30 eth0 default routing interface selected (according to /proc) HPING 205.153.63.30 (eth0 205.153.63.30): NO FLAGS are set, 40 headers + 0 data bytes 46 bytes from 205.153.63.30: flags=RA seq=0 ttl=126 id=786 win=0 rtt=4.4 ms 46 bytes from 205.153.63.30: flags=RA seq=1 ttl=126 id=1554 win=0 rtt=4.5 ms 46 bytes from 205.153.63.30: flags=RA seq=2 ttl=126 id=2066 win=0 rtt=4.6 ms 46 bytes from 205.153.63.30: flags=RA seq=3 ttl=126 id=2578 win=0 rtt=5.5 ms 46 bytes from 205.153.63.30: flags=RA seq=4 ttl=126 id=3090 win=0 rtt=4.5 ms --- 205.153.63.30 hping statistic --- 5 packets tramitted, 5 packets received, 0% packet loss round-trip min/avg/max = 4.4/4.7/5.5 ms
When using ICMP, this is what one of the replies from the output looks like:
Otherwise, the output will be almost identical to the default behavior.46 bytes from 205.153.63.30: icmp_seq=0 ttl=126 id=53524 rtt=2.2 ms
If you want more information, you can use -V for verbose mode. Here is what a reply looks like with this option:
46 bytes from 172.16.2.236: flags=RA seq=0 ttl=63 id=12961 win=0 rtt=1.0 ms
tos = 0 len = 40
seq = 0 ack = 108515096
sum = a5bc urp = 0Other options that control the general behavior of hping include -c to set the number of packets to send, -i to set the time between packets, -n for numeric output (no name resolution), and -q for quiet output (just summary lines when done).
Another group of options allows you to control the contents of the packet header. For example, the -a option can be used to specify an arbitrary source address for a packet. Here is an example:
In this case, the packet has been sent from a computer whose actual source address is 172.16.3.234. The packet, however, will have 205.153.63.30 in its IP header as the source address. Of course, any reply from the destination will go back to the spoofed source address, not the actual source address. If this a valid address that belongs to someone else, they may not look kindly on your testing.lnx1# hping2 -a 205.153.63.30 172.16.2.236 eth0 default routing interface selected (according to /proc) HPING 172.16.2.236 (eth0 172.16.2.236): NO FLAGS are set, 40 headers + 0 data bytes --- 172.16.2.236 hping statistic --- 4 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms
Spoofing source addresses can be useful when testing router and firewall setup, but you should do this in a controlled environment. All routers should be configured to drop any packets with invalid source addresses. That is, if a packet claims to have a source that is not on the local network or that is not from a device for which the local network should be forwarding a packet, then the source address is illegal and the packet should be dropped. By creating packets with illegal source addresses, you can test your routers to be sure they are, in fact, dropping these packets. Of course, you need to use a tool like ethereal or tcpdump to see what is getting through and what is blocked.[36]
[36]If this is all you are testing, you may prefer to use a specialized tool like egressor.The source port can be changed with the -s option. The TTL field can be set with the -t option. There are options to set the various TCP flags: -A for ACK, -F for FIN, -P for PUSH, -R for RST, -S for SYN, and -U for URG. Oddly, although you can set the urgent flag, there doesn't seem to be a way to set the urgent pointer. You can set the packet size with the -d option, set the TCP header length with the -O option, and read the packet's data from a file with the -E option. Here is an example of sending a DNS packet using data in the file data.dns:
hping generated an error on my system with this command, but the packet was sent correctly.bsd2# hping -2 -p 53 -E data.dns -d 31 205.153.63.30
Be warned, constructing a usable data file is nontrivial. Here is a crude C program that will construct the data needed for this DNS example:
#include <stdio.h>
main( )
{
FILE *fp;
fp=fopen("data.dns", "w");
fprintf(fp, "%c%c%c%c", 0x00, 0x01, 0x01, 0x00);
fprintf(fp, "%c%c%c%c", 0x00, 0x01, 0x00, 0x00);
fprintf(fp, "%c%c%c%c", 0x00, 0x00, 0x00, 0x00);
fprintf(fp, "%c%s", 0x03, "www");
fprintf(fp, "%c%s", 0x05, "cisco");
fprintf(fp, "%c%s%c", 0x03, "com", 0x00);
fprintf(fp, "%c%c%c%c", 0x00, 0x01, 0x00, 0x01);
fclose(fp);
}Finally, hping can also be put in dump mode so that the contents of the reply packets are displayed in hex:
bsd2# hping -c 1 -j 172.16.2.230
HPING 172.16.2.230 (ep0 172.16.2.230): NO FLAGS are set, 40 headers + 0 data
bytes
46 bytes from 172.16.2.230: flags=RA seq=0 ttl=128 id=60017 win=0 rtt=2.1 ms
0060 9706 2222 0060 088f 5f0e 0800 4500
0028 ea71 0000 8006 f26b ac10 02e6 ac10
02ec 0000 0a88 0000 0000 1f41 a761 5014
0000 80b3 0000 0000 0000 0000
--- 172.16.2.230 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 2.1/2.1/2.1 ms
9.1.1.2. nemesis
nemesis, whose author is identified only as Obecian in the documentation, is actually a family of closely related command-line tools designed to generate packets. They are nemesis-arp, nemesis-dns, nemesis-icmp, nemesis-igmp, nemesis-ospf, nemesis-rip, nemesis-tcp, and nemesis-udp. Each, as you might guess, is designed to construct and send a particular type of packet. The inclusion of support for protocols like OSPF or IGMP really sets nemesis apart from similar tools.Here is an example that sends a TCP packet:
The -v option is for verbose mode. Without this option, the program sends the packet but displays nothing on the screen. Use this option to test your commands and then omit it when you embed the commands in scripts. The -S and -D options give the source and destination addresses. You can use the -x and -y to set source and destination ports. If you want to specify flags, you can use the -f option. For example, if you add -fS -fA to the command line, the SYN and ACK flags will be set. (Many firewalls will block packets with some combinations of SYN and ACK flags but will pass packets with different combinations. Being able to set the SYN and ACK flags can be useful in testing these firewalls.)bsd2# nemesis-tcp -v -D 205.153.63.30 -S 205.153.60.236 TCP Packet Injection -=- The NEMESIS Project 1.1 (c) 1999, 2000 obecian <[email protected]> 205.153.63.30 [IP] 205.153.60.236 > [Ports] 42069 > 23 [Flags] [TCP Urgent Pointer] 2048 [Window Size] 512 [IP ID] 0 [IP TTL] 254 [IP TOS] 0x18 [IP Frag] 0x4000 [IP Options] Wrote 40 bytes TCP Packet Injected
Here is an example setting the SYN and ACK flags and the destination port:
Notice the program performs silently without the -v option. A number of additional options are described in the Unix manpages.bsd2# nemesis-tcp -S 172.16.2.236 -D 205.153.63.30 -fS -fA -y 22
The other programs in the nemesis suite work pretty much the same way. Here is an example for sending an ICMP ECHO REQUEST:
The -i option specifies the type field in the ICMP header. In this case, the 8 is the code for an ECHO_REQUEST message. The destination should respond with an ECHO_REPLY.bsd2# nemesis-icmp -v -S 172.16.2.236 -D 205.153.63.30 -i 8 ICMP Packet Injection -=- The NEMESIS Project 1.1 (c) 1999, 2000 obecian <[email protected]> [IP] 172.16.2.236 > 205.153.63.30 [Type] ECHO REQUEST [Sequence number] 0 [IP ID] 0 [IP TTL] 254 [IP TOS] 0x18 [IP Frag] 0x4000 Wrote 48 bytes ICMP Packet Injected
The -P option can be used to read the data for the packet from a file. For example, here is the syntax to send a DNS query.
Although it appears the data has been sent correctly, I have seen examples when the packets were not correctly sent despite appearances. So, be warned! It is always a good idea to check the output of a packet generator with a packet sniffer just to make sure you are getting what you expect.bsd2# nemesis-dns -v -S 172.16.2.236 -D 205.153.63.30 -q 1 -P data.dns DNS Packet Injection -=- The NEMESIS Project 1.1 (c) 1999, 2000 obecian <[email protected]> [IP] 172.16.2.236 > 205.153.63.30 [Ports] 42069 > 53 [# Questions] 1 [# Answer RRs] 0 [# Authority RRs] 0 [# Additional RRs] 0 [IP ID] 420 [IP TTL] 254 [IP TOS] 0x18 [IP Frag] 0x4000 [IP Options] 00 01 01 00 00 01 00 00 00 00 00 00 03 77 77 .............ww 77 05 63 69 73 63 6F 03 63 6F 6D 00 00 01 00 w.cisco.com.... 01 . Wrote 40 bytes DNS Packet Injected
9.1.1.3. Other tools
There are a number of other choices. ipfilter is a suite of programs for creating firewalls. Supplied with some operating systems, including FreeBSD, ipfilter has been ported to a number of other platforms. One of the tools ipfilter includes is ipsend. Designed for testing firewalls, ipsend is yet another tool to construct packets. Here is an example:
ipsend is not the most versatile of tools, but depending on what system you are using, you may already have it installed.bsd2# ipsend -v -i ep0 -g 172.16.2.1 -d 205.153.63.30 Device: ep0 Source: 172.16.2.236 Dest: 205.153.63.30 Gateway: 172.16.2.1 mtu: 1500
Yet another program worth considering is sock. sock is described in the first volume of Richard W. Stevens' TCP/Illustrated and is freely downloadable. While sock doesn't give the range of control some of these other programs give, it is a nice pedagogical tool for learning about TCP/IP. Beware, there are other totally unrelated programs called sock.
Finally, some sniffers and analyzers support the capture and retransmission of packets. Look at the documentation for the sniffer you are using, particularly if it is a commercial product. If you decide to use this feature, proceed with care. Retransmission of traffic, if used indiscriminately, can create some severe problems.
9.1.2. Load Generators
When compared to custom packet generators, load generators are at the opposite extreme of the continuum for packet injectors. These are programs that generate traffic to stress-test a network or devices on a network. These tools can help you judge the performance of your network or diagnose problems. They can also produce a considerable strain on your network. You should use these tools to test systems offline, perhaps in a testing laboratory prior to deployment or during scheduled downtime. Extreme care should be taken before using these tools on a production network. Unless you are absolutely convinced that what you are doing is safe and reasonable, don't use these tools on production networks.Almost any application can be used to generate traffic. A few tools, such as ping and ttcp, are particularly easy to use for this purpose. For example, by starting multiple ping sessions in the background, by varying the period between packets with the -i option, and by varying the packet sizes with the -s option, you can easily generate a wide range of traffic loads. Unfortunately, this won't generate the type of traffic you may need for some types of tests. Two tools, spray and mgen, are described here. The better known of these is probably spray. (It was introduced in Chapter 4, "Path Characteristics".) It is also frequently included with systems so you may already have a copy. mgen is one of the most versatile.
9.1.2.1. spray
spray is useful in getting a rough idea of a computer's network performance, particularly its interface. spray, on the local computer, communicates with the rpc.sprayd daemon on the remote system being tested. (You'll need to make sure this is running on the remote system.) It effectively floods the remote system with a large number of fixed-length UDP packets. The remote daemon, generally started by inetd, receives and counts these packets. The local copy of spray queries the remote daemon to determine the number of packets that were successfully received. By comparing the number of packets sent to the number received, spray can calculate the number of packets lost.Here is an example of spray using default values:
bsd2# spray sol1
sending 1162 packets of lnth 86 to 172.16.2.233 ...
in 0.12 seconds elapsed time
191 packets (16.44%) dropped
Sent: 9581 packets/sec, 804.7K bytes/sec
Rcvd: 8006 packets/sec, 672.4K bytes/secYou should not be alarmed that packets are being dropped. The idea is to send packets as fast as possible so that the interface will be stressed and packets will be lost. spray is most useful in comparing the performance of two machines. For example, you might want to see if your server can keep up with your clients. To test this, you'll want to use spray to send packets from the client to the server. If the number of packets dropped is about the same, the machines are fairly evenly matched. If a client is able to overwhelm a server, then you may have a potential problem.
In the previous example, spray was run on bsd2, flooding sol1. Here are the results of running spray on sol1, flooding bsd2 :
sol1# spray bsd2
sending 1162 packets of length 86 to 172.16.2.236 ...
610 packets (52.496%) dropped by 172.16.2.236
36 packets/sec, 3144 bytes/secUnfortunately, while spray can alert you to a problem, it is unable to differentiate among the various reasons why a packet was lost -- collision, slow interface, lack of buffer space, and so on. The obvious things to look at are the speed of the computer and its interfaces.
9.1.2.2. MGEN
The Multi-Generator Toolset or MGEN is actually a collection of tools for generating traffic, receiving traffic, and analyzing results. The work of Brian Adamson at the Naval Research Laboratory, this sophisticated set of tools will give you a high degree of control over the shape of the traffic you generate. However, you aren't given much control over the actual UDP packets the utility sends -- that's not the intent of the tool. For its intended uses, however, you have all the control you are likely to need.The traffic generation tool is mgen. It can be run in command-line mode or by using the -g option in graphical mode. At its simplest, it can be used with command-line options to generate traffic. Here is a simple example:
bsd2# mgen -i ep0 -b 205.153.63.30:2000 -r 10 -s 64 -d 5
MGEN: Version 3.1a3
MGEN: Loading event queue ...
MGEN: Seeding random number generator ...
MGEN: Beginning packet generation ...
(Hit <CTRL-C> to stop)Trying to set IP_TOS = 0x0
MGEN: Packets Tx'd : 50
MGEN: Transmission period: 5.018 seconds.
MGEN: Ave Tx pkt rate : 9.964 pps.
MGEN: Interface Stats : ep0
Frames Tx'd : 55
Tx Errors : 0
Collisions : 0
MGEN: Done.Other options for mgen include setting the interface (-i), the destination address and port (-b), the packet rate (-r), the packet size (-s), and the duration of the flow in seconds (-d ). There are a number of other options described in the documentation, such as the type of service and TTL fields.
The real strength of mgen comes when you use it with a script. Here is a very simple example of a script called demo :
The first line tells mgen to start generating traffic as soon as the program is started. (An absolute start time can also be specified.) The second line creates a flow with an ID of 1 that starts 1 millisecond into a run that has port 5000 on 205.153.63.30 as its destination. The traffic is 5 packets per second, and each packet is 64 bytes in length. The third line tells mgen to modify the flow with ID 1. 5000 milliseconds (or 5 seconds) into the flow, packet generation should switch to a Poission distribution with a rate of 20 packets per second. The last line terminates the flow at 15,000 milliseconds. While this script has only one flow, a script can contain many.START NOW 00001 1 ON 205.153.63.30:5000 PERIODIC 5 64 05000 1 MOD 205.153.63.30:5000 POISSON 20 64 15000 1 OFF
Here is an example of the invocation of mgen with a script:
bsd2# mgen -i ep0 demo
MGEN: Version 3.1a3
MGEN: Loading event queue ...
MGEN: Seeding random number generator ...
MGEN: Beginning packet generation ...
MGEN: Packets Tx'd : 226
MGEN: Transmission period: 15.047 seconds.
MGEN: Ave Tx pkt rate : 15.019 pps.
MGEN: Interface Stats : ep0
Frames Tx'd : 234
Tx Errors : 0
Collisions : 0
MGEN: Done.For many purposes, mgen is the only tool from the MGEN tool set that you will need. But for some purposes, you will need more. drec is a receiver program that can log received data. mgen and drec can be used with RSVP (with ISI's rsvpd). You will recall that with RSVP, the client must establish the session. drec has this capability. Like mgen, drec has an optional graphical interface. In addition to mgen and drec, the MGEN tool set includes a number of additional utilities that can be used to analyze the data collected by drec.
One last note on load generators -- software load generators assume that the systems they run on are fast enough to generate enough traffic to adequately load the system being tested. In some circumstances, this will not be true. For some applications, dedicated hardware load generators must be used.
|  | |
| 8.6. Microsoft Windows |  | 9.2. Network Emulators and Simulators |
