From: "Dan Searle" <dan@intrago.co.uk>
To: netfilter@lists.netfilter.org
Subject: Optimize large iptables by hashing on MAC address help
Date: Fri, 11 Oct 2002 10:30:55 +0100 [thread overview]
Message-ID: <002801c27108$e75d6590$0800000a@wormhole> (raw)
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.
next reply other threads:[~2002-10-11 9:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-11 9:30 Dan Searle [this message]
-- strict thread matches above, loose matches on Subject: below --
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
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='002801c27108$e75d6590$0800000a@wormhole' \
--to=dan@intrago.co.uk \
--cc=netfilter@lists.netfilter.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