All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Jarod Neuner <j.neuner@networkharbor.com>
Cc: David Miller <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: IGMP sent to Foreign VLAN
Date: Thu, 09 Oct 2008 14:31:32 +0200	[thread overview]
Message-ID: <48EDF9A4.2090908@trash.net> (raw)
In-Reply-To: <1223508896.24688.95.camel@deepthought.nh.local>

Jarod Neuner wrote:
>> Patrick McHardy wrote:
>> We've been talking about an IFF_ALLVLAN flag on netdev a while
>> ago, which would disable VLAN hardware filters, similar to
>> IFF_ALLMULTI. An additional flag on the ethernet device could
>> indicate that it should receive unknown VLANs directly. That
>> would introduce some possible inconsistencies however since the
>> flag could be set without the VLAN code even loaded, in which
>> case it would not have any effect.
> 
> My original thought was to do something like this in net/core/dev.c
> using a method similar to handle_bridge or handle_macvlen.  So, if the
> packet doesn't get handled by the ptype_base list and IFF_ALLVLAN is
> set, then strip the header and let the packet through.  The sticky point
> would be whether or not this policy should be enabled by default, as it
> seems to be in other network stacks.

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.

>> Another possibility would be to use a catch-all VLAN device with
>> VID 0xfff (reserved for implementation use). This would allow
>> to configure priority mappings, header reordering etc. and have
>> separate statistics. The drivers could just use the magic VID
>> as an indication to disable filtering, but I would still suggest
>> to add the IFF_ALLVLAN flag because its useful on its own.
> 
> Most switches treat VLAN 1 as the "Default" or "Administration" VLAN.
> It might make sense to map VLAN 1 to the incoming interface, and then
> use that as a catch all.  Then again, that might be a terrible idea as
> well. =)

I prefer 0xfff because its not used for anything else so far.
Especially the administrative VLAN (even if only by convention)
doesn't seem by a good idea because its pretty likely you
would treat it differently from unknown VLANs wrt. filtering.

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.


  reply	other threads:[~2008-10-09 12:31 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 [this message]
2008-10-09 16:18         ` Jarod Neuner
2008-10-10 16:28           ` Patrick McHardy
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=48EDF9A4.2090908@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.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.