Study Guide
Networking Tools
-
University:
Massachusetts Institute of Technology -
Course:
6.829 | Computer Networks Academic year:
2019
-
Views:
132
Pages:
11
Author:
Emilee Donaldson
Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science
6.829 Fall 2002
Networking Tools
September 13, 2001
Overview. In this tutorial, we will cover tools that are commonly used in networking research (not to mention in the "real world" for debugging). We begin with netstat and tcpdump, describing briefly how to use each of these tools by looking at a live TCP connection and making sense of their output. We'll use netstat to describe one of the subtleties of the TCP state machine.
Next, we'll look at a couple of lookup-based tools, dig and whois, that provide information about DNS information about hosts, and registry information about names and networks, respectively.
We will then move on to standard network measurement tools, ping and, more interestingly, traceroute, describing how they work and what they do (and don't) tell you.
Finally, for those of you who don't know perl, I'll show how to "tie things together" by demon- strating a simple perl script that takes our trace and counts bytes to destination IP addresses and ASes
1 tcpdump and netstat
How does tepdump work? For BSD-derived kernels, the Berkeley Packet Filter (BPF) is available. The filter places the device driver into promiscuous mode, receives from the driver receive all transmitted and received packets. These packets are then run through a user-specified filter, so that only the packets that the user specifies as interesting will be passed to the user process. What about the costliness to constantly trapping to the keruel for small reads? A timeout value with batch reads solves this problem.
Filtering is done in the kernel. This limits the amount of data that must be copied from the kernel into user spac
Here is what the output from topdump host i eth0 aros.ron.lcs.mit.edu port ssh from my machine will look like:
08:52:34.173548 ginseng.lcs.mit.edu.3524> aros.ron.lcs.mit.edu.sah: S
821658836:821658836(0) win 32120 (DF)
08:52:34.256660 aros.ron.ics.mit.edu.ssh> ginseng.ics.mit.edu.3524: 3
2025096886:2025096886 (0) ack 821658837 vin 57344
08:52:34.256691 ginseng.lcs.mit.edu.3524> aros.ron.lcs.mit.edu.sah:
ack 1 win 32120 (DF)
08:52:34.342643 aros.ron.lcs.mit.edu.sah > ginseng.lcs.mit.edu.3524: P
1:41(40) ack 1 win 57920 (DF)
08:52:34.342671 ginseng.lcs.mit.edu.3524> aros.ron.lcs.mit.edu.sah:
ack 41 win 32080 (DF)
1
What's going on with the timestamp option? For example, why not just mark a packet with the current time it was sent? (Requires clock synchronization.)
Information included in cach line: a timestamp, source and destination (IP address and port), TCP flags, segment info (start, end, size), acks, window size, various other TCP options. The "P" Hag stands for "push" the received data to the application as soon as possible. Notice the 3-way handshake. Also, notice the process of tearing down a connection:
tcp
0 O ginseng.lcs.mit.ed:3524 aros.ron.1cs.mit.ed:ssh ESTABLISHED
tcp
O ginseng.lcs.mit.ed: 3524 aros.ron.lcs.mit.ed:ssh TIME WAIT
Briefly describe the state transition diagram as the summary of the "rule set" for how TCP behaves.
Why does the connection go into the time wait state? Note this is also called the "2MSL" (maximum segment lifetime) state. The end that performs the active close does not know if the final ACK was ever received, so it doesn't know that the other side closed the connection. Just because the FIN arrives, we can't assume that the connection is closed. segments may arrive out of order.
Can you think of various attacks on TCP? Sequence number hijacking is one example. SYN flood attacks is another? How would you defend against a SYN flood? One approach is something called "SYN Cookies", whereby the sender does not set up state for a connection until after the three-way handshake is completed (rather than going into the SYN received state immediately after receiving the first SYN). This will be described in lecture in the coming weeks.
2 Lookup Tools: dig and whois
dig is a DNS lookup utility. It's similar to nslookup, but dig is more powerful. You can query for various types of records. Most common (and default) is the "A" record, which maps a DNS name to an IP address.
Here is some example output for a lookup on my machine. Notice that the query is for an "A" record. dig also returns a bunch of other useful information. For example, it returns the "NS"
2
4 PERL
Why does the trace look the way it does? It's basically because we're looking at the receiver's side: the sender fills the congestion window, we're ACK-ing a window's worth of packets, and the process repeats itself.
11
3 Measurement Tools: ping and traceroute
ping is a simple program that sends an ICMP "Echo Request" message to a machine and waits to hear an ICMP "Echo Reply". It's basically useful for telling if a particular host is responding (and therefore that it's actually turned on, on the network, etc.). Ping also shows an RTT value for each request/reply pair, and a sequence number. Ping will give a summary of the loss rate as well. Note that the RTT may not be completely accurate, since ICMP is not on the fast path for many routers. Interesting options include "f" (flood, sometimes requires root), "c" (send a certain number of packets), "s" (specify packet size, sometimes useful for looking at fragmentation).
Try sending pings of large packet size, and watching the IP ID in tepdump.
traceroute is a tool for getting some idea about the route that a particular host sees to a certain destination. Traceroute sends an IP packet with increasing TTL values (actually, 3 per TTL value), and listens for ICMP "TIME EXCEEDED" responses for each hop along the path to the host. Some important things to note about traceroute:
• Each hop specified an interface (from which the time-exceeded message was sent), not a host or a router. A path may traverse more than one hop on a particular router.
6
4 PERL
It may be the case that the source of the time-exceeded message is set to the IP address of the outgoing interface on the return path to the host, rather than the interface that the packet arrived on. This can produce some surprising results.
A failure in a traceroute does not indicate a failure at that point (necessarily). It could indicate a failure along the reverse path, for example. Additionally, "*" does not indicate a failure condition, necessarily, this might mean, for example, that the router does not respond to ICMP messages,
Note that the version of traceroute on most machines doesn't support the "A" option. You can either do this manually (as above), fine the RPM or appropriate existing package for your machine, or download the "Nanog Traceroute from http://nms.lcs.mit.edu/6.829/other/
traceroute-nanog.tar.gz, and compile it for your particular machine (note that traceroute either
requires superuser privileges to run, or you must set it to "setuid root", or you will get permission
errors).
Networking Tools
of 11
Recommended Documents
Report
Tell us what’s wrong with it:
Thanks, got it!
We will moderate it soon!
Free up your schedule!
Our EduBirdie Experts Are Here for You 24/7! Just fill out a form and let us know how we can assist you.
Take 5 seconds to unlock
Enter your email below and get instant access to your document