Monitoring VLANs with tcpdump

[Marco Matarazzo]

Hi all,

is there any way to monitor a VLAN trunk with tcpdump using expressions?
Quick example:

if I do a tcpdump -n -e -ttt -vv -i fxp0 on my trunk interface this is what
I get:

Aug 26 16:39:16.067000 0:9:7b:3f:5c:8 0:2:b3:8f:87:3 8100 64: 802.1Q vid 29
pri 0 a.b.c.d.port > e.f.g.h.1056 (etc. etc.)

if I want to filter on, say, host I can't do a
tcpdump -n -e -ttt -vv -i fxp0 host a.b.c.d
because it returns nothing. I can of course do a grep on the output, but it
takes far more resources... I can of course do a simultaneous dump on all
vlans, but there are too many... :)

Any trick?

Cheers,
]\/[arco

[Chris Cappuccio]

Either

1. Use an ethernet card that does hardware vlan tagging. That way
the BPF layer already sees untagged packets

or

2. Run tcpdump on the vlan interfaces

The problem is that the BPF layer only sees the tagged packet and has
no way of decoding it and knowing that kind of packet it actually is beyond
the fact that it's VLAN tagged. Once the packet is passed to the if_vlan
interface, it untags the packet and passes it to bpf again as the untagged
version.

The reason tcpdump itself can show you the packets beyond the tags is that
it has its own method to untag the packets and see what they are.

Post by Marco Matarazzo
Hi all,
is there any way to monitor a VLAN trunk with tcpdump using expressions?
if I do a tcpdump -n -e -ttt -vv -i fxp0 on my trunk interface this is what
Aug 26 16:39:16.067000 0:9:7b:3f:5c:8 0:2:b3:8f:87:3 8100 64: 802.1Q vid 29
pri 0 a.b.c.d.port > e.f.g.h.1056 (etc. etc.)
if I want to filter on, say, host I can't do a
tcpdump -n -e -ttt -vv -i fxp0 host a.b.c.d
because it returns nothing. I can of course do a grep on the output, but it
takes far more resources... I can of course do a simultaneous dump on all
vlans, but there are too many... :)
Any trick?
Cheers,
]\/[arco

[Damien Miller]

Post by Chris Cappuccio
Either
1. Use an ethernet card that does hardware vlan tagging. That way
the BPF layer already sees untagged packets

...

Post by Chris Cappuccio
2. Run tcpdump on the vlan interfaces

3. patch tcpdump to detag 802.1q frames and call ether_if_print() on them.

-d

[Marco Matarazzo]

Post by Damien Miller

Post by Chris Cappuccio
1. Use an ethernet card that does hardware vlan tagging. That way
the BPF layer already sees untagged packets

...

Post by Chris Cappuccio
2. Run tcpdump on the vlan interfaces

3. patch tcpdump to detag 802.1q frames and call ether_if_print() on them.

Are you referring to this one Damien?

http://archives.neohapsis.com/archives/openbsd/2003-07/0827.html

I'll try that as soon as I update that router to 3.3 (probably will wait for
3.4 though... :)

Thanks!
]\/[arco

[Chris Cappuccio]

Post by Damien Miller
3. patch tcpdump to detag 802.1q frames and call ether_if_print() on them.

This is basically what tcpdump does now. But it only works when you are
asking BPF for 'ALL' packets or 'ALL' 0x8100 (802.1Q) packets (if that's
even possible through BPF?). Once you tell BPF to filter based on any
criteria, it currently doesn't look past the 802.1Q tag.

When you run 'tcpdump -ni fxp0 host 1.2.3.4', tcpdump is passing 'host 1.2.3.4'
up to BPF which does the filtering and sends back the matches. Since BPF
does not know how to look inside 802.1Q tagged packets, it will never match
host 1.2.3.4.

[Marco Matarazzo]

Post by Chris Cappuccio
1. Use an ethernet card that does hardware vlan tagging. That way
the BPF layer already sees untagged packets

Time to go shopping then! :) Have you any clues about which card is best of
the two ones that support Hardware VLAN tagging, txp based or ti based?

Post by Chris Cappuccio
2. Run tcpdump on the vlan interfaces

Of course! :)
Problem is, that I wanted to know to which VLAN belonged a certain spoofed
IP packet. The simplest thing that come to mind, is simply tcpdump the
trunk, since all traffic passes there! I remember that on tcpdump on linux,
you could do something like:

tcpdump -n -e -vv -ttt -i eth0 vlan and host a.b.c.d

but, as you're telling me, there's no such way to operate in OpenBSD...

Post by Chris Cappuccio
The reason tcpdump itself can show you the packets beyond the tags is that
it has its own method to untag the packets and see what they are.

And I thought that, since it can decode it, it could also filter ON it :)

Thaks a lot!
]\/[arco

Post by Chris Cappuccio

Post by Marco Matarazzo
Hi all,
is there any way to monitor a VLAN trunk with tcpdump using expressions?
if I do a tcpdump -n -e -ttt -vv -i fxp0 on my trunk interface this is what
Aug 26 16:39:16.067000 0:9:7b:3f:5c:8 0:2:b3:8f:87:3 8100 64: 802.1Q vid 29
pri 0 a.b.c.d.port > e.f.g.h.1056 (etc. etc.)
if I want to filter on, say, host I can't do a
tcpdump -n -e -ttt -vv -i fxp0 host a.b.c.d
because it returns nothing. I can of course do a grep on the output, but it
takes far more resources... I can of course do a simultaneous dump on all
vlans, but there are too many... :)
Any trick?
Cheers,
]\/[arco

--
One nation, under surveillance.

[Chris Cappuccio]

Post by Marco Matarazzo

Post by Chris Cappuccio
1. Use an ethernet card that does hardware vlan tagging. That way
the BPF layer already sees untagged packets

Time to go shopping then! :) Have you any clues about which card is best of
the two ones that support Hardware VLAN tagging, txp based or ti based?

if_ti is for gigabit networks and txp is for 10/100

Post by Marco Matarazzo
Problem is, that I wanted to know to which VLAN belonged a certain spoofed
IP packet. The simplest thing that come to mind, is simply tcpdump the
trunk, since all traffic passes there! I remember that on tcpdump on linux,
tcpdump -n -e -vv -ttt -i eth0 vlan and host a.b.c.d
but, as you're telling me, there's no such way to operate in OpenBSD...

Nope. And if you do it with hardware filtering, then you are going to see
that there is still no way of knowing which vlan the packets are associated
with.

Post by Marco Matarazzo
And I thought that, since it can decode it, it could also filter ON it :)

Nope. tcpdump's method of displaying 802.1Q packets does not reflect BPF's
(lack of) capabilities to filter on those packets.