From: Oscar N <oscar@kiruna.se>
To: netfilter@vger.kernel.org
Subject: Re: [Ebtables-user] Log VLANs without interfaces.
Date: Mon, 15 Nov 2010 14:36:45 +0100 [thread overview]
Message-ID: <8d96ecb4677f1ab6e0e43aaf626336d1@localhost> (raw)
In-Reply-To: <7B021863-0FB7-4199-A855-1B2A57950652@gmail.com>
Hi!
We did this a couple of years ago due to shitty switches that didn't even
had the possibility to filter out packets from rouge DHCP servers.
What we did was using a central database and scripts on the linux boxes
instead that handled all the hard work of setting up/removing interfaces.
Worked very well and we also incorporated multiple routing tables and per
user packet shaping. Maybe that would be another approach to solve the
problem.
/Regards Oscar
On Mon, 15 Nov 2010 10:47:31 +0000, Asher Awelan <asherawelan@gmail.com>
wrote:
> SCENARIO:
> I have inherited a hospitality solution which uses 802.11q tagging on
it's
> switched network for the purpose of room identification, i.e. one port
per
> room.
> My current handling of this is working but not stable and is memory
heavy.
> Currently I have the 250 (I know!) VLANs on eth1.x as interfaces and
have
> bridged them on br0.
> I am using ebtables to log which mac addresses are using which vlan tag
> and then doing some cron processing to charge data use to the rooms.
> However, this is pretty intensive on the network/ifconfig management.
>
> QUESTION:
> Is there a way to broute the vlans to the eth1 interface and not have to
> create every interface and register every vlan... or perhaps strip the
vlan
> id (after logging of course)...
>
> Further clarification can be given of course.
> I know this is a ridiculous scenario, however these are my parameters
> within which to work.
>
> Thank you kindly,
>
------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> Ebtables-user mailing list
> Ebtables-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ebtables-user
parent reply other threads:[~2010-11-15 13:36 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <7B021863-0FB7-4199-A855-1B2A57950652@gmail.com>]
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=8d96ecb4677f1ab6e0e43aaf626336d1@localhost \
--to=oscar@kiruna.se \
--cc=netfilter@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).