From: Bart De Schuymer <bdschuym@pandora.be>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: Aijaz Baig <aijazbaig1@gmail.com>,
netfilter@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: packet flow - ebtables broute DROP target
Date: Thu, 15 Jul 2010 21:26:33 +0200 [thread overview]
Message-ID: <4C3F60E9.3090106@pandora.be> (raw)
In-Reply-To: <alpine.LSU.2.01.1007151616400.7169@obet.zrqbmnf.qr>
Jan Engelhardt schreef:
> On Thursday 2010-07-15 16:02, Aijaz Baig wrote:
>
>> unfamiliar with it, here are the links to the same:
>> http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html for the document
>> and http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png for the
>> picture.
>>
>
> Use http://jengelh.medozas.de/images/nf-packet-flow.png
>
>
>> Im trying to understand what happens to a packet which is DROPped in the
>> BROUTING chain of the broute table. If I have understood correctly from
>> the document above, it goes to L3 where the routing subsystem can decide
>> where to send the packet to depending on L3 information in it isn't it?
>>
>
> In net/core/dev.c, the packet is passed to all "taps". Taps include
> raw sockets (think tcpdump), but also bridge and the IPvX layers
> themselves. Each of them basically gets a copy, thus it is important to
> not have an address on the ethernet interface (so that the IPvX tap
> ignores it). Only the bridge interface should have an address, because
> the bridge code will pass it to IPvX on its own.
>
>
When using a brouter, you actually assign IP addresses to the bridge
ports (different subnets) instead of the virtual bridge interface
itself. IP traffic is then DROPped in the BROUTE chain, so it's not
bridged. See http://ebtables.sourceforge.net/examples/real.html#example1
for an example usage.
cheers,
Bart
--
Bart De Schuymer
www.artinalgorithms.be
next prev parent reply other threads:[~2010-07-15 19:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1DB91DF937A4544C81E636468B91C21C06F1EC28@CNSHGSMBS03.ad4.ad.alcatel.com>
2010-07-15 8:08 ` 'HELP ME PLEASE. libnetfilter_queue issue MAI JIN
2010-07-15 8:08 ` MAI JIN
2010-07-15 13:44 ` Mistick Levi
2010-07-15 14:02 ` packet flow - ebtables broute DROP target Aijaz Baig
2010-07-15 14:34 ` Jan Engelhardt
2010-07-15 19:26 ` Bart De Schuymer [this message]
2010-07-16 8:05 ` Aijaz Baig
2010-07-16 16:54 ` Bart De Schuymer
2010-07-16 17:06 ` Payam Chychi
2010-07-15 19:26 ` Bart De Schuymer
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=4C3F60E9.3090106@pandora.be \
--to=bdschuym@pandora.be \
--cc=aijazbaig1@gmail.com \
--cc=jengelh@medozas.de \
--cc=netfilter-devel@vger.kernel.org \
--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 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.