From: Patrick McHardy <kaber@trash.net>
To: Jarod Neuner <j.neuner@networkharbor.com>
Cc: netdev@vger.kernel.org
Subject: Re: IGMP sent to Foreign VLAN
Date: Fri, 10 Oct 2008 18:28:06 +0200 [thread overview]
Message-ID: <48EF8296.3070507@trash.net> (raw)
In-Reply-To: <1223569129.24688.159.camel@deepthought.nh.local>
Jarod Neuner wrote:
> On Thu, 2008-10-09 at 07:31 -0500, Patrick McHardy wrote:
>> I don't think we should change the default, it would probably
>> catch some people by surprise. It might not be handled properly
>> by packet filtering rules etc.
>
> On the other hand, I was surprised that VLAN packets were being dropped
> altogether. Net admins tend to assign a link to a particular VLAN with
> little regard to the VLAN configuration of the hosts on that link. I'm
> thinking of two general situations:
>
> 1) If the kernel is resident on an application device (PC, Multimedia
> Device, SOHO Router, etc.), and a packet for a particular VLAN reaches
> the network interface with a correct MAC and a correct IP, then they
> were probably delivered correctly, whether that host is configured with
> that VLAN ID or even if the VLAN module is loaded.
>
> 2) If the kernel is configured to route incoming VLAN packets, and a
> packet arrives with an unconfigured VLAN ID, then it seems perfectly
> reasonable to route it as if it had no VLAN tag.
>
> I'm sure someone has a setup that expects that foreign VLANs will be
> dropped - but I suspect far more are generally indifferent to the
> policy. There might even be a handful that will be pleasantly surprised
> when IGMP snooping suddenly starts to work.
Possible, but besides the fact that this has been our default
since even before VLAN was merged, a reason why this absolutely
has to be manually enabled is that it requires to disable hardware
filters for consistent, driver-independant behaviour.
>> So .. would you be interested in implementing this properly?
>> I think its a good change and I could help you if needed or
>> take care of some parts like the drivers myself.
>
> I've got quite a bit on my plate at the moment, but I will give it a
> shot. I'll try to come up with some of the IFF_ALLVLAN functionality
> over the next few days and get back to you.
Great, thanks.
next prev parent reply other threads:[~2008-10-10 16:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-06 19:51 IGMP sent to Foreign VLAN Jarod Neuner
2008-10-07 23:07 ` David Miller
2008-10-07 23:53 ` Patrick McHardy
2008-10-08 23:34 ` Jarod Neuner
2008-10-09 12:31 ` Patrick McHardy
2008-10-09 16:18 ` Jarod Neuner
2008-10-10 16:28 ` Patrick McHardy [this message]
2008-10-10 22:45 ` Benny Amorsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48EF8296.3070507@trash.net \
--to=kaber@trash.net \
--cc=j.neuner@networkharbor.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.