On Mon, Nov 12, 2007 at 02:57:16PM -0800, David Miller wrote:
quoted text
> From: "Chris Friesen" <cfriesen@nortel.com>
> Date: Mon, 12 Nov 2007 16:43:24 -0600
> 
> > David Miller wrote:
> > 
> > > When you select VLAN, you by definition are asking for non-VLAN
> > > traffic to be elided.  It is like plugging the ethernet cable
> > > into one switch or another.
> > 
> > For max functionality it seems like the raw eth device should show 
> > everything on the wire in promiscuous mode.
> > 
> > If we want to sniff only the traffic for a specific vlan, we can sniff 
> > the vlan device.
> 
> VLAN settings are a filter of sorts, much like plugging into
> one switch or another filters traffic physically.
> 
> If you don't want that filter, turn the VLAN settings off.

I don't really agree with that view. Having spent a lot of time with
tcpdump on production systems, I can say that sometimes you'd like to
be aware that one of your VLANs is wrong and you'd simply like to
sniff the wire to guess the correct tag. And on production, you simply
cannot remove other VLANs, otherwise you disrupt the service.

Basically, what generally happens is that the guy responsible for the
switch tells you "it's OK now", but for you it isn't and you cannot
access the switch.

If the solution is to disable VLAN hardware acceleration, I agree that
it is very risky to do that without the user being aware of it. But at
least we should be able to do this by any means (eg: ethtool) without
disabling what's running.

And since you made the parallel with a switch, when you receive tagged
traffic on a switch port, you generally can mirror that port to another
one and catch all VLANs at once. A new feature that is starting to appear
is the ability to mirror tagged traffic to a VLAN on another port (which
means you get a double 802.1q tag). This is useful for inter-site links
between data-centers for instance.

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html