For this experiment, we will reuse the same network as in Section 5.5.
In this exercise, we'll observe IP fragmentation of UDP datagrams.
You'll need two terminal windows open on "romeo" and one open on "juliet".
First, run
ifconfig eth1
on each host, and make a note of the MTU of the eth1 interface on each. Now, we'll verify this value experimentally.
On "romeo", start tcpdump with
sudo tcpdump -en -i eth1 "not tcp"
(Note that we use the "not tcp" filter to exclude the status/information data exchanged by iperf3 over TCP. Also note that we are monitoring the output in real time, rather than saving to a file.)
In the second terminal window on "romeo", start an iperf3 server with
iperf3 -s
While that is running, on "juliet" run
iperf3 -c romeo -u -k 1 -l 512
to send a UDP packet with a 512B payload. (Note that an Ethernet, IP, and UDP header will be added to the payload.) Observe the result in the tcpdump window, where both the payload length and the total size of the Ethernet frame is shown. (At the beginning of each iperf3 transaction, you may observe two very small packets which establish that the server is listening on the specified port - you can ignore these packets.)
Repeat the iperf3 client command, but increase the length of the payload by modifying the -l argument, until IP fragmentation occurs.
Stop the tcpdump with Ctrl+C. Then, start a new tcpdump on "romeo" with the capture saved to a file:
sudo tcpdump -enx -i eth1 -w $(hostname -s)-no-ip-fragment.pcap "not tcp"
Make sure the iperf3 server is running on "romeo". Then, on "juliet", repeat the iperf3 command to send a UDP datagram with the maximum payload length at which IP fragmentation does not occur.
Stop tcpdump with Ctrl+C. Then, start a new tcpdump with
sudo tcpdump -enx -i eth1 -w $(hostname -s)-ip-fragment.pcap "not tcp"
and on "juliet", run
iperf3 -c romeo -u -k 1 -l 2048
Stop tcpdump and the iperf3 server with Ctrl+C.
Transfer the packet captures to your laptop with scp.
Lab report: What is the maximum iperf3 payload size (e.g. largest -l argument) that can be sent without IP fragmentation?
Lab report: Explain the maximum iperf3 payload size in terms of MTU and header lengths. What headers are appended to the iperf3 payload, and what size is each header? Describe the total size (including payload + headers) at each layer.
Lab report: What condition is necessary and sufficient to avoid IP fragmentation?
Lab report: Explain the tcpdump output for the iperf3 flow with -l 2048 in terms of the IP header fields (i.e., id, offset, flags, length) that are used in fragmentation.
Lab report: When IP fragmentation occurs, only one of the fragments has the UDP header. How do you verify this fact from the tcpdump output?
In this exercise, we'll observe maximum payload size that can be sent in a UDP datagram.
You'll need on terminal window open on "romeo" and two open on "juliet".
First, run
iperf3 -s
on "romeo".
On "juliet", start tcpdump with
sudo tcpdump -en -i eth1 "not tcp"
(Note that we use the "not tcp" filter to exclude the status/information data exchanged by iperf3 over TCP. Also note that we are monitoring the output in real time, rather than saving to a file.)
In the second terminal window on "juliet", run
iperf3 -c romeo -u -k 1 -l 10000
Repeat the iperf3 client command, but increase the length of the payload by modifying the -l argument, until the system refuses to send anything.
Lab report: What is the maximum size of the iperf3 UDP payload that the system can send, even when fragmentation is allowed? Explain this value in terms of the header sizes and the "length" header field. (Hint: imagine an interface with a very large MTU, so that there is no IP fragmentation, and the entire payload is sent in a single UDP datagram. How many bits are allocated for the "length" field in the IP header? What is the maximum value that this field can hold? What limitation does this impose on underlying protocol layers?)
Once you are done with this part of the lab , proceed to the next part