tcpdump filters for data collection

Discussion in 'Linux Networking' started by Neil Jones, Dec 3, 2008.

  1. Neil Jones

    Neil Jones Guest

    I want to collect data on a network and map the data flow and
    system/port traffic. There are 2 scenarios of data collection here. The
    first is to collect IP traffic only. In this method I do not want the
    data portion of the IP packet (need IP address, source/destination ports

    The second is to collect traffic that will show all the routing
    protocols (non-IP) used on this network. Today while collecting the
    data, I saw several HSRP packets. I don't know what portion of the
    packet is sufficient to capture for this purpose.

    I used the "-s 0" option on tcpdump which captures the whole packet.
    That is making the dump file large. Any help with the filters is
    appreciated to capture the non-data portion of the packets.

    Thank you in advance.

    Neil Jones, Dec 3, 2008
    1. Advertisements

  2. "-s 20" to give you a snap length of 20 bytes will limit your collection
    to just the IP header, minus any options. You'd have to make it longer
    to capture the TCP and UDP headers, which have the port info you say you
    want. However, because the IP header can have options, the total length
    of the IP header can vary. Usually by _not_ specifying the snap length,
    you'd get the default of 68, which is usually enough to include TCP and
    UDP headers. In other words, using "-s 0" is exactly what you don't
    want to do. You have to use one snap length for all collection with a
    single tcpdump process. If you want to use different snap lengths for
    different filters, then you need to run each filter in a separate
    tcpdump process.

    So, the IP header is _at_least_ 20 bytes. The TCP header is _at_least_
    20 more bytes, or the UDP header is 8 more bytes, or the ICMP "header"
    is _at_least_ 4 more bytes. (ICMP doesn't really have a header, but the
    first 4 bytes are common to all ICMP types.)

    If you're collecting on a multi-protocol network, then you can specify
    "ip" as the filter value to make sure you're only getting IP packets
    (i.e., no NetBEUI, IPX/SPX, DECNet, whatever). Note that if you've got
    switches sending spanning tree packets, that's a layer 2 protocol, so
    you'll filter them out, too. Do you care?

    HSRP is a Cisco-only protocol that is multicast to udp/1985, so the
    above combination of snap length and filter will capture enough to
    record who is doing the multicasting (i.e., the source address). Only
    if you can define what you want to do with HSRP, can you tweak the
    filter and snap length meaningfully.

    Use "-s 20" or nothing at all (let it default). Don't use "-s 0."
    Use "ip" as the filter or nothing at all, depending on what you want.
    Go with just those until you really figure out what you want.
    Allen Kistler, Dec 3, 2008
    1. Advertisements

  3. Neil Jones

    Neil Jones Guest

    Thank you for replying and explaining the -s options. I will capture
    using all the default options (68 bytes header and all protocols) to
    start with. Later I will start trimming it to IP only. Part of the
    challenge is that there is encrypted traffic on this network. I am
    trying to map the encrypted flow as well on this network.

    Thank you once again.

    Neil Jones, Dec 3, 2008
  4. Neil Jones

    Rick Jones Guest

    I can never remember - does snaplen include the data-link header?
    Even if it does not, 20 bytes gets you just the IPv4 header. It won't
    even get you an entire IPv6 header.

    rick jones
    Rick Jones, Dec 3, 2008
  5. Good point. I checked. You need another 16 bytes for the Layer 2
    header. So "-s 36" to get the whole IPv4 IP header.

    It's also true that IPv6 has a longer IP header than IPv4. The IPv6 IP
    header is 40 bytes. I live in a world (North America, commercial) where
    ISPs still use IPv4, so there's little incentive for anyone else to do so.
    Allen Kistler, Dec 3, 2008
  6. Oops. I meant there's little incentive for anyone else to switch.
    Allen Kistler, Dec 3, 2008
  7. Neil Jones

    Rick Jones Guest

    Still, the lesson of the old Fram oil filter commercials might apply -
    their "you can pay me now, or you can pay be later" tag line to get
    one to buy the fram oil filter today to avoid an expensive engine
    repair tomorrow - in this case though, getting your sw prepared for
    IPv6 :) If you do it now, then chances are it won't be needed but will
    be there if it is. If you don't do it now, you are increasing the
    chances it will be needed later - I'm sure it is some offshoot of
    Murphy's Law applied to programming :)

    rick jones
    Rick Jones, Dec 4, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.