Linux Netfilter discussions
 help / color / mirror / Atom feed
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 --]

  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