Linux Netfilter discussions
 help / color / mirror / Atom feed
* Optimize large iptables by hashing on MAC address help
@ 2002-10-11  9:30 Dan Searle
  0 siblings, 0 replies; 3+ messages in thread
From: Dan Searle @ 2002-10-11  9:30 UTC (permalink / raw)
  To: netfilter

Hi,

I am trying to optimise a very large set of iptables rules that match
packets based on MAC address. The tables contain thousands of rules matching
packets using the --mac-source matching rule, e.g...

...etc...
ACCEPT     tcp  --  anywhere             anywhere           MAC
00:02:E3:16:73:BB tcp dpt:webcache
ACCEPT     udp  --  anywhere             anywhere           MAC
00:02:E3:16:73:BB udp dpt:webcache
ACCEPT     tcp  --  anywhere             anywhere           MAC
00:C1:26:01:DA:92 tcp dpt:webcache
ACCEPT     udp  --  anywhere             anywhere           MAC
00:C1:26:01:DA:92 udp dpt:webcache
...etc...

The problem is that the system seems to be spending a lot of time matching
these rules, as the firewall handles up to 10Mbits of traffic at high load.
To optimise the process I want to create 16 (or perhaps more) sub-tables
based on the Nth least significant bits of the source MAC address (a sort of
hashing), i.e.

* The INPUT chain would contain 16 sub-table jump rules matching the 4 least
sig. bits of the MAC source like this....

INPUT_0   all  --  anywhere             anywhere     PART-MAC
xx:xx:xx:xx:xx:x0
INPUT_1   all  --  anywhere             anywhere     PART-MAC
xx:xx:xx:xx:xx:x1
INPUT_2   all  --  anywhere             anywhere     PART-MAC
xx:xx:xx:xx:xx:x2
INPUT_3   all  --  anywhere             anywhere     PART-MAC
xx:xx:xx:xx:xx:x3
...etc...
INPUT_E   all  --  anywhere             anywhere     PART-MAC
xx:xx:xx:xx:xx:xE
INPUT_F   all  --  anywhere             anywhere     PART-MAC
xx:xx:xx:xx:xx:xF

* Each of the rules will then be dumped into the relevant custom sub-chains,
i.e...
The INPUT_2 chain will contain all the MAC address rules ending in :x2
e.g...

ACCEPT     tcp  --  anywhere             anywhere           MAC
00:C1:26:01:DA:92 tcp dpt:webcache
ACCEPT     udp  --  anywhere             anywhere           MAC
00:C1:26:01:DA:92 udp dpt:webcache
ACCEPT     tcp  --  anywhere             anywhere           MAC
00:B5:23:21:FF:72 tcp dpt:webcache
ACCEPT     udp  --  anywhere             anywhere           MAC
00:B5:23:21:FF:72 udp dpt:webcache
...etc....

Using this hashing method, instead of each packet potentially being compared
against say 1024 rules, only approx. 64 (1024/16) rules would need to be
considered, dramatically increasing the speed at which packets are filtered.

So my question is, is there a "PART-MAC" matching rule, or some other low
level matching rule which could be used to achieve the same effect?

Cheers, Dan...

P.S.
Sorry about such a large post, but I don't know how I could explain it in a
more consise manner.




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Optimize large iptables by hashing on MAC address help
@ 2002-10-11 16:01 Dan Searle
  2002-10-11 16:59 ` Robert P. J. Day
  0 siblings, 1 reply; 3+ messages in thread
From: Dan Searle @ 2002-10-11 16:01 UTC (permalink / raw)
  To: netfilter

Re,

I've had a look at the linux/net/ipv4/netfilter/ipt_mac.c source and had a
thought...

It wouldn't be too difficult to add an extra parameter to the mac match
module to allow masked matching, i.e. add a --mac-mask parameter which would
allow the user to specify a bit mask so that only the un-masked bits of the
6 byte mac address were compared, e.g...

iptables -A INPUT -m mac --mac-source 00:00:00:00:00:02 --mac-mask
00:00:00:00:00:0F -j ACCEPT

...meaning that only the least significant 4 bits of the mac source are
compared against the specified mac source parameter.

Perhaps if the person in charge of writing the ipt_mac.c file reads this
they may consider adding this masking functionality to the module. I would
have a go myself, but I'm not too confident at kernel hacking! :-)

Cheers, Dan...

P.S.
Aplolgies to Brad Morgan, I replied to you personaly first, by mistake
instead of to the list!

----- Original Message -----
From: "Brad Morgan" <B-Morgan@concentric.net>
To: "Dan Searle" <dan@intrago.co.uk>
Sent: Friday, October 11, 2002 4:05 PM
Subject: RE: Optimize large iptables by hashing on MAC address help


> Dan,
>
> I'm not sure if code exists to accomidate your needs but I've attached a
> message to this list from a while back that may improve your performance.
> I'm not associated with this project and am not using it on my small
> firewall.
>
> Regards,
>
> Brad Morgan
>





^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Optimize large iptables by hashing on MAC address help
  2002-10-11 16:01 Optimize large iptables by hashing on MAC address help Dan Searle
@ 2002-10-11 16:59 ` Robert P. J. Day
  0 siblings, 0 replies; 3+ messages in thread
From: Robert P. J. Day @ 2002-10-11 16:59 UTC (permalink / raw)
  To: netfilter mailing list

On Fri, 11 Oct 2002, Dan Searle wrote:

> Re,
> 
> I've had a look at the linux/net/ipv4/netfilter/ipt_mac.c source and had a
> thought...
> 
> It wouldn't be too difficult to add an extra parameter to the mac match
> module to allow masked matching, i.e. add a --mac-mask parameter which would
> allow the user to specify a bit mask so that only the un-masked bits of the
> 6 byte mac address were compared, e.g...
> 
> iptables -A INPUT -m mac --mac-source 00:00:00:00:00:02 --mac-mask
> 00:00:00:00:00:0F -j ACCEPT
> 
> ...meaning that only the least significant 4 bits of the mac source are
> compared against the specified mac source parameter.

but how frequently would such a mask be used?  after all, conventional
wisdom suggests that, while you have the freedom to assign IP addresses
any way you want, most people just have to work with the MAC addresses
on the cards they're given.  and if a card burns out and you replace it,
the new MAC address may not be programmable.

so i'm just curious -- aside from the original poster, how many others
would take advantage of this feature?

rday



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-10-11 16:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-11 16:01 Optimize large iptables by hashing on MAC address help Dan Searle
2002-10-11 16:59 ` Robert P. J. Day
  -- strict thread matches above, loose matches on Subject: below --
2002-10-11  9:30 Dan Searle

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox