tcpdump filters for data collection

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
etc).

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.

NJ

Neil Jones wrote:
> 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
> etc).
>
> 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.

"-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.

So:
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 wrote:
> Neil Jones wrote:
>> 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
>> etc).
>>
>> 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.
>
> "-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.
>
> So:
> 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.

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.

NJ

In comp.os.linux.networking Allen Kistler <(E-Mail Removed)> wrote:
> "-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

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
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Rick Jones wrote:
> In comp.os.linux.networking Allen Kistler <(E-Mail Removed)> wrote:
>> "-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
>
> 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.

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 wrote:
> Rick Jones wrote:
>> In comp.os.linux.networking Allen Kistler <(E-Mail Removed)> wrote:
>>> "-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
>>
>> 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.
>
> 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.

Oops. I meant there's little incentive for anyone else to switch.

In comp.os.linux.networking Allen Kistler <(E-Mail Removed)> wrote:
> > 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.

> Oops. I meant there's little incentive for anyone else to switch.

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
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...