Re: [PATCHv6 0/3] Interface group patches

Re: [PATCHv6 0/3] Interface group patches

[Wolfgang Walter]

From: Patrick McHardy
> 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.

Using ifindex instead of string matching the interface name in -i and -o would 
be a serious problem as it changes the semantics.

1) Now you can match a non existing interface. This is certainly used. I.e. 
with vlan interfaces, ppp etc.
2) Now your rule will match an interface even if the ifindex of the interface 
changes. This is used (i.e. you activate a backup interface and rename it, 
build new bridges etc.).

If one wants to use the ifindex instead of a string match on the name one 
should explicitly request that (i.e. by using "-i =eth0" or something like 
that).

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
-
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

Re: [PATCHv6 0/3] Interface group patches

[Patrick McHardy]

Wolfgang Walter wrote:
> From: Patrick McHardy
>> 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.
> 
> Using ifindex instead of string matching the interface name in -i and -o would 
> be a serious problem as it changes the semantics.
> 
> 1) Now you can match a non existing interface. This is certainly used. I.e. 
> with vlan interfaces, ppp etc.
> 2) Now your rule will match an interface even if the ifindex of the interface 
> changes. This is used (i.e. you activate a backup interface and rename it, 
> build new bridges etc.).
> 
> If one wants to use the ifindex instead of a string match on the name one 
> should explicitly request that (i.e. by using "-i =eth0" or something like 
> that).


Don't worry, it will subscribe to netdevice events and adjust the
ifindex when necessary. For userspace its still a device name match.

Re: [PATCHv6 0/3] Interface group patches

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1261 bytes --]



On Fri, 23 Nov 2007, Patrick McHardy wrote:

> Wolfgang Walter wrote:
>> From: Patrick McHardy
>>> 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.
>> 
>> Using ifindex instead of string matching the interface name in -i and -o 
>> would be a serious problem as it changes the semantics.
>> 
>> 1) Now you can match a non existing interface. This is certainly used. I.e. 
>> with vlan interfaces, ppp etc.
>> 2) Now your rule will match an interface even if the ifindex of the 
>> interface changes. This is used (i.e. you activate a backup interface and 
>> rename it, build new bridges etc.).
>> 
>> If one wants to use the ifindex instead of a string match on the name one 
>> should explicitly request that (i.e. by using "-i =eth0" or something like 
>> that).
>
>
> Don't worry, it will subscribe to netdevice events and adjust the
> ifindex when necessary. For userspace its still a device name match.

Also for "-i ppp+"?

Best regards,

 				Krzysztof Olędzki

Re: [PATCHv6 0/3] Interface group patches

[Patrick McHardy]

Krzysztof Oledzki wrote:
> 
> 
> On Fri, 23 Nov 2007, Patrick McHardy wrote:
> 
>> Wolfgang Walter wrote:
>>> From: Patrick McHardy
>>>> 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.
>>>
>>> Using ifindex instead of string matching the interface name in -i and 
>>> -o would be a serious problem as it changes the semantics.
>>>
>>> 1) Now you can match a non existing interface. This is certainly 
>>> used. I.e. with vlan interfaces, ppp etc.
>>> 2) Now your rule will match an interface even if the ifindex of the 
>>> interface changes. This is used (i.e. you activate a backup interface 
>>> and rename it, build new bridges etc.).
>>>
>>> If one wants to use the ifindex instead of a string match on the name 
>>> one should explicitly request that (i.e. by using "-i =eth0" or 
>>> something like that).
>>
>>
>> Don't worry, it will subscribe to netdevice events and adjust the
>> ifindex when necessary. For userspace its still a device name match.
> 
> Also for "-i ppp+"?


No, see above :) Its a single device match, for wildcards it will
still use the pattern-based matching.

Re: [PATCHv6 0/3] Interface group patches

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1591 bytes --]



On Fri, 23 Nov 2007, Patrick McHardy wrote:

> Krzysztof Oledzki wrote:
>> 
>> 
>> On Fri, 23 Nov 2007, Patrick McHardy wrote:
>> 
>>> Wolfgang Walter wrote:
>>>> From: Patrick McHardy
>>>>> 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.
>>>> 
>>>> Using ifindex instead of string matching the interface name in -i and -o 
>>>> would be a serious problem as it changes the semantics.
>>>> 
>>>> 1) Now you can match a non existing interface. This is certainly used. 
>>>> I.e. with vlan interfaces, ppp etc.
>>>> 2) Now your rule will match an interface even if the ifindex of the 
>>>> interface changes. This is used (i.e. you activate a backup interface and 
>>>> rename it, build new bridges etc.).
>>>> 
>>>> If one wants to use the ifindex instead of a string match on the name one 
>>>> should explicitly request that (i.e. by using "-i =eth0" or something 
>>>> like that).
>>> 
>>> 
>>> Don't worry, it will subscribe to netdevice events and adjust the
>>> ifindex when necessary. For userspace its still a device name match.
>> 
>> Also for "-i ppp+"?
>
>
> No, see above :) Its a single device match, for wildcards it will
> still use the pattern-based matching.

Right, sorry. It seems I overlooked the most important part. :(

Best regards,

 				Krzysztof Olędzki

[PATCHv6 0/3] Interface group patches

[Laszlo Attila Toth]

Hi Dave,

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. The netfilter patch
is ready but future plan is the same for ip/tc commands (except
the ifgroup value change which happens via "ip link set" command).

The first patch is a fix in the rtnl socket interface.

An u_int32_t member was added to net devices indicating the interface
group number of the device which can be get/set via netlink.

The xt_ifgroup netfilter match is for checking this value with an
optional mask.

Other patches are for userpace programs:
 * iptables
 
 * iproute2. Because kernel 2.6.24-rc1 introduced a new enum value,
   IFLA_NET_NS_PID, and it wasn't in the iproute2 code, the first
   patch simply adds this value. The second patch adds support of
   interface group.

Usage:
 ip link set eth0 group 4    # set
 ip link set eth0 group 0    # unset
 iptables -A INPUT -m ifgroup --ifgroup-in 4/0xf -j ACCEPT
 iptables -A FORWARD -m ifgroup --ifgroup-in 4  ! --ifgroup-out 5 -j DROP

Patches:
 [1/3] rtnetlink: setlink changes are unprotected; with single notification
 [2/3] Interface group: core (netlink) part
 [3/3] Netfilter Interface group match
 [iptables]Interface group match
 [iproute 1/2] Added IFLA_NET_NS_PID as in kernel v2.6.24-rc1
 [iproute 2/2] Interface group as new ip link optio
--
Laszlo Attila Toth

Re: [PATCHv6 0/3] Interface group patches

[Jan Engelhardt]

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

>The netfilter patch
>is ready but future plan is the same for ip/tc commands (except
>the ifgroup value change which happens via "ip link set" command).

How can it be useful in conjunction with tc?

Re: [PATCHv6 0/3] Interface group patches

[Laszlo Attila Toth]

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.

> 
>> The netfilter patch
>> is ready but future plan is the same for ip/tc commands (except
>> the ifgroup value change which happens via "ip link set" command).
> 
> How can it be useful in conjunction with tc?

jamal wrote it previously:
http://marc.info/?l=linux-netdev&m=119253403415810&w=2

-- 
Attila
-
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

Re: [PATCHv6 0/3] Interface group patches

[David Miller]

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.
-
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

Re: [PATCHv6 0/3] Interface group patches

[Patrick McHardy]

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.

Re: [PATCHv6 0/3] Interface group patches

[David Miller]

From: Patrick McHardy <kaber@trash.net>
Date: Wed, 21 Nov 2007 01:25:54 +0100

> 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.

Fair enough :)

Re: [PATCHv6 0/3] Interface group patches

[Laszlo Attila Toth]

David Miller írta:
> From: Patrick McHardy <kaber@trash.net>
> Date: Wed, 21 Nov 2007 01:25:54 +0100
> 
>> 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.
> 
> Fair enough :)
> 

If this means the patch is ok, please apply it. Thanks.

--
Attila
-
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

Re: [PATCHv6 0/3] Interface group patches

[Balazs Scheidler]

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