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. Similarly if you are reading tcpdump output on the sending machine; 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 and how switches can flood traffic 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 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.)