From: Matt Zagrabelny <mzagrabe@d.umn.edu>
To: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
Cc: netfilter@vger.kernel.org
Subject: Re: Netfilter Performance when using MAC filter
Date: Thu, 01 Nov 2007 08:17:32 -0500 [thread overview]
Message-ID: <1193923052.5142.9.camel@grateful.d.umn.edu> (raw)
In-Reply-To: <4729A4D6.2020106@plouf.fr.eu.org>
[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]
On Thu, 2007-11-01 at 11:05 +0100, Pascal Hambourg wrote:
> Matt Zagrabelny a écrit :
> > On Wed, 2007-10-31 at 20:19 +0100, Pascal Hambourg wrote:
> >
> >>Matt Zagrabelny a écrit :
> >>
> >>>If so, you can do MAC filtering (performance shouldn't matter as the MAC
> >>>address is in the link header)
> >>
> >>Can you please elaborate about the relationship beween filtering
> >>performance and the address layer ?
> >
> > There is nothing to elaborate on. ;)
> >
> > The frame contains the MAC address. This is what iptables will be
> > looking at. If the box running iptables is on the same network/vlan as
> > the rest of the traffic it is expecting to filter, then it will have MAC
> > addresses of actual hosts, however, if traffic is coming from a
> > different network/vlan then said traffic will have been routed and the
> > frame will have changed, thus the MAC address will be the MAC of the
> > network boundary, namely the router/gateway.
>
> Sorry, but I still do not see the point in "performance shouldn't matter
> as the MAC address is in the link header". Performance (read : speed) is
> mostly related to the number of rules, isn't it ?
Okay, I see now. Performance would be related to the number of rules
that each packet needs to be tested against not against the criterion of
the match. Caveat: perhaps layer7 matching would be slower or using the
owner module, I don't know about these modules.
--
Matt Zagrabelny - mzagrabe@d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems & Services
PGP key 1024D/84E22DA2 2005-11-07
Fingerprint: 78F9 18B3 EF58 56F5 FC85 C5CA 53E7 887F 84E2 2DA2
He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-11-01 13:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-31 16:23 Netfilter Performance when using MAC filter Babu Skeitson
2007-10-31 18:26 ` Matt Zagrabelny
2007-10-31 18:41 ` Grant Taylor
2007-10-31 19:19 ` Pascal Hambourg
2007-10-31 19:33 ` Matt Zagrabelny
2007-11-01 10:05 ` Pascal Hambourg
2007-11-01 13:17 ` Matt Zagrabelny [this message]
2007-11-01 14:55 ` Pascal Hambourg
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=1193923052.5142.9.camel@grateful.d.umn.edu \
--to=mzagrabe@d.umn.edu \
--cc=netfilter@vger.kernel.org \
--cc=pascal.mail@plouf.fr.eu.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