netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Balazs Scheidler <bazsi@balabit.hu>
To: Patrick McHardy <kaber@trash.net>
Cc: David Miller <davem@davemloft.net>,
	panther@balabit.hu, jengelh@computergmbh.de,
	netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: [PATCHv6 0/3] Interface group patches
Date: Wed, 21 Nov 2007 16:56:02 +0100	[thread overview]
Message-ID: <1195660563.6691.5.camel@bzorp.balabit> (raw)
In-Reply-To: <47437B12.9090009@trash.net>


On Wed, 2007-11-21 at 01:25 +0100, Patrick McHardy wrote:
> David Miller wrote:
> > From: Laszlo Attila Toth <panther@balabit.hu>
> > Date: Tue, 20 Nov 2007 14:52:12 +0100
> > 
> >> Jan Engelhardt írta:
> >>> On Nov 20 2007 14:14, Laszlo Attila Toth wrote:
> >>>> This is the 6th version of our interface group patches.
> >>>>
> >>>> The interface group value can be used to manage different interfaces
> >>>> at the same time such as in netfilter/iptables.
> >>> I take it you could not use...?
> >>> 	iptables -i iif1 -j dosomething
> >>> 	iptables -i iif2 -j dosomething
> >> This kind of usage requires static interface names. But there are 
> >> dynamic interfaces such as ppp, where the actual name is not always 
> >> known or sometimes they exist sometimes not. It is difficult to use 
> >> iptables this way, and every ifup/ifdown requires change in the iptables 
> >> ruleset (donwload it, modify and upload to the kernel). It may be too slow.
> > 
> > This is actually not true these days.
> > 
> > When network devices are created user events are generated and the
> > user can rename the device however they like using a mapping table of
> > any kind.
> > 
> > And at such point the problem you present doesn't actually exist, you
> > can know what the device will be named.
> > 
> > And if rule loading dynamically is slow, we should fix that instead of
> > creating infrastructure and interfaces we don't actually need.
> 
> 
> I actually like this feature. Matching on names in iptables
> has always been one of the major bottlenecks, taking
> (according to my last measurement, which is some time ago)
> about 1-2% of the total performance. This is of course in
> large parts because the interface match is present on *every*
> rule, but still some way to logically group interfaces seems
> useful to me, not only for iptables, but also for routing rules,
> traffic classifiers, af_packet sockets etc.
> 
> I'm working on the incremental ruleset changing API BTW :)
> One of the changes will be that interface matching is not
> a default part of every rule, and without wildcards it will
> use the ifindex. But since the cost of this feature seems
> pretty low, I don't see a compelling reason against it.

We are also using interface groups from userspace applications (hence
the netlink notification). 

ppp comes up, an interface is created according to the pppd
configuration, which then assigns the interface to the given group.
another application (a proxy based firewall in our example) listens to
this notification and binds to the new interface as well.

-- 
Bazsi

-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2007-11-21 15:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-20 13:14 [PATCHv6 0/3] Interface group patches Laszlo Attila Toth
2007-11-20 13:14 ` [PATCHv6 1/3] rtnetlink: setlink changes are unprotected; with single notification Laszlo Attila Toth
2007-11-20 13:14   ` [PATCHv6 2/3] Interface group: core (netlink) part Laszlo Attila Toth
2007-11-20 13:14     ` [PATCHv6 3/3] Netfilter Interface group match Laszlo Attila Toth
2007-11-20 13:14       ` [PATCHv6 iptables]Interface " Laszlo Attila Toth
2007-11-20 13:14         ` [PATCHv6 iproute 1/2] Added IFLA_NET_NS_PID as in kernel v2.6.24-rc1 Laszlo Attila Toth
2007-11-20 13:14           ` [PATCHv6 iproute 2/2] Interface group as new ip link option Laszlo Attila Toth
2007-11-23 13:25             ` Lutz Jaenicke
2007-11-23 13:39         ` [PATCHv6 iptables]Interface group match Lutz Jaenicke
2007-11-29 12:50           ` Laszlo Attila Toth
2007-11-29 16:16             ` Patrick McHardy
2007-11-29 16:23               ` Laszlo Attila Toth
2007-11-29 16:27                 ` Patrick McHardy
2007-11-29 17:14                   ` Jan Engelhardt
2007-11-29 17:15                     ` Patrick McHardy
2007-11-27 13:10       ` [PATCHv6 3/3] Netfilter Interface " Patrick McHardy
2007-11-23 13:18     ` [PATCHv6 2/3] Interface group: core (netlink) part Lutz Jaenicke
2007-11-27 13:07     ` Patrick McHardy
2007-11-27 13:07   ` [PATCHv6 1/3] rtnetlink: setlink changes are unprotected; with single notification Patrick McHardy
2007-11-20 13:26 ` [PATCHv6 0/3] Interface group patches Jan Engelhardt
2007-11-20 13:52   ` Laszlo Attila Toth
2007-11-20 21:42     ` David Miller
2007-11-21  0:25       ` Patrick McHardy
2007-11-21  1:17         ` David Miller
2007-11-22  9:05           ` Laszlo Attila Toth
2007-11-21 15:56         ` Balazs Scheidler [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-11-22 15:25 Wolfgang Walter

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=1195660563.6691.5.camel@bzorp.balabit \
    --to=bazsi@balabit.hu \
    --cc=davem@davemloft.net \
    --cc=jengelh@computergmbh.de \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=panther@balabit.hu \
    /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).