== A growing realization about _tcpdump_ and reading IP traffic

Here is a gotcha about reading _tcpdump_ output that recent events have
been tattooing on my forehead:

> The only sure way to tell whether a packet is going to your gateway
> or to something on the local network is to look at the destination
> Ethernet address.

To put it another way: a packet being sent to your network's gateway
does not have the gateway's IP address in it. Thus, reading _tcpdump_
output without Ethernet addresses is not really telling you whether a
packet was really sent to your gateway or whether it was just [[floating
by on the network NetworkWeirdness]]. Similarly if you are reading
_tcpdump_ output on the [[sending machine WeirdRoutingMystery]]; until
you look at the destination MAC, you don't actually know where the
machine is sending the packets, you just think you know.

This is obvious once you think about it (assuming that you know enough
about how IP works), as is its interaction with _tcpdump_ being
[[promiscuous ../linux/PromiscuousModeEffects]] and how switches can
[[flood traffic NetworkWeirdness]] through your network. But you do have
to think about it, and not doing so has tripped me up at least twice
now. It's certainly not intuitive that more or less the only thing
your machine's IP stack does with your gateway's IP address is to [[ARP
http://en.wikipedia.org/wiki/Address_Resolution_Protocol]] for its
Ethernet address.

(I think one reason that this is so easy to overlook is that it feels
like a layering violation. It's rational to think that the use of an IP
gateway should be visible in the IP headers of a packet, instead of only
showing up one lever lower.)