netfilter.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: ebtables & VLAN redirect
Date: Sun, 27 Jun 2010 21:14:59 -0500	[thread overview]
Message-ID: <4C2805A3.4070801@riverviewtech.net> (raw)
In-Reply-To: <AANLkTikWc-CNXMieyxv2lB69UphqQRsjjJATJYrpjkMK@mail.gmail.com>

Anatoly Muliarski wrote:
> Thank you for your response.

You are welcome.

> Unfortunately, I need to redirect the traffic from all VLANs. In 
> other words, the task comes to selective redirecting of the traffic 
> from all VLANs to a specified one. The redirecting must be 
> unidirected, only for the traffic that comes from all VLANs.

Will you please provide an example of what redirection you are talking 
about?

Remember that you can set a default policy of DROP in your BROUTING 
chain to cause the packets to be routed like normal.  So any frames that 
you don't want bridged will simply be routed like normal.  There by only 
bridging the frames that you want to.

> Yes, it works now, but for the other purpose.

Ok.

> That would work but I need to redirect traffic that is not destined 
> to VLAN 9 and ARP-proxy trick does not work for this case.

So you are going to have to intercept the traffic and alter the 
destination MAC (and possibly IP) address(es)?

I believe that EBTables can do that.  If not, you can probably have 
IPTables work on bridged frames, and I know that it will do that.

> Thanks for the ideas. I'll try it. The main problem is to avoid 
> unnecessary bridging attempts for all VLANs( as it would waste CPU 
> time for try to transmit a packet to a hundred VLAN ). Another way is 
> to write a target extension to ebtables to replace a vlan tag to a 
> desired one, but as I need to do it selectively I need ebtables' 
> capabilities to analyze vlan-tagged packets and there are no ones ...

I'm still not sure that you can't do what you want to do with EBTables 
and / or IPTables.

Remember that EBTables will learn where MAC addresses are and won't 
flood frames out (go in to dumb hub mode).

> Or to write something like a udp-broadcast-relay daemon...

I don't think you will be bridging too many packets.  (That is unless I 
really misunderstand what you are wanting to do.)

Can you provide an example (sanitized if need be) of what you are trying 
to do?  Including (hypothetical) source and destination MAC and IP 
addresses on either side of the bridge?



Grant. . . .

  reply	other threads:[~2010-06-28  2:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-26 12:43 ebtables & VLAN redirect Anatoly Muliarski
2010-06-26 16:41 ` Grant Taylor
2010-06-27  6:04   ` Anatoly Muliarski
2010-06-28  2:14     ` Grant Taylor [this message]
2010-06-28 17:33       ` Anatoly Muliarski
2010-06-28 20:45         ` Grant Taylor
2010-06-29 18:15           ` Anatoly Muliarski
2010-06-29 19:29             ` Grant Taylor
2010-06-29 19:31               ` Grant Taylor
2010-06-30  3:20                 ` /dev/rob0
2010-06-30  3:33                   ` Grant Taylor
2010-06-30 20:54                 ` Anatoly Muliarski
2010-06-30 21:09                   ` Grant Taylor
2010-06-30 21:21                     ` Grant Taylor

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=4C2805A3.4070801@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --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).