From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: iptables resources consumed
Date: Thu, 03 Jul 2008 04:34:33 -0500 [thread overview]
Message-ID: <486C9D29.804@riverviewtech.net> (raw)
In-Reply-To: <VPOP31.4.0e.20080703103819.796.18.1.00149acd@matrixindia>
On 7/3/2008 12:09 AM, Elison Niven wrote:
> Grant - Thanks a lot for your reply.
You are welcome.
> I would just like to discard them.
Ok. Then a default of DROP (somewhere) will probably suffice.
> Yes, I would be using a custom built kernel for PowerPc. It is now
> clear that I will have a maximum of 256 (may be 256*2 or 3 !) rules
> on eth0 and just 1 rule on eth2.
Um, there is a big difference in 256, 512, and 768 rules. IMHO, even if
it is 256, you still want to do some optimization to reduce the number
of rule checks that are needed.
> To make things complex, the PowerPc communicates with the DSPs
> through ethernet on eth2. Each DSP has a control Port number and the
> PowerPc controls the DSPs through packets sent at this port number on
> the DSP. The DSPs respond to these commands through ethernet packets
> (that are received on eth2).
>
> Such packets need to be sent to a process on the PowerPc and not
> forwarded out on eth0.
Ok... Now it is starting to sound like you want any and all traffic to
/ from the DSPs to go through the bridge (eth0 & eth2) like normal
*except* for traffic to / from the control port. Now you are wanting to
send the control port traffic somewhere other than though eth0. Do I
have this correct?
> The rule on eth2 will be : If source port of the packet is not a DSP
> control Port Number , send the packet out from eth0 and replace
> source IP with ip = eth0.
Ok... The last part about the source IP can easily be handled by a
simple MASQUERADE / SNAT rule on eth0. The redirection may be a bit
more interesting.
> If all the DSPs have different control port numbers that would
> increase the checking - Source IP and Source Port per packet, So I
> prefer to have the same control port numbers on all the DSPs.
At first glance this would seem nice. However I've dealt with software
that believes that any traffic coming in on a port is from a specific
source and as such there has to be multiple different ports to identify
multiple different sources. Just make sure that you are not dealing
with any thing like there here.
> Now If the DSP itself *fakes* the source IP of the packets it
> generates, then may be the rule can be simpler : Check the source
> port of the packet. If it is not equal to the control port number
> just send it out *as it is* from eth0. If source port is equal to the
> control port number, send it to a local process.
I don't see how the DSP would even know what IP it would need to fake
as, much less believe that it would do it. Besides, if it did, it would
tend to break the IP routing / NATing that is being done (same subnet on
multiple interfaces).
> Yeah, the mere thought of it puts me in panic! I do not have any
> prior experience with iptables. As from your experience, Do you a
> think a custom powerc kernel running at 400 MHx, 256 MB DDR2 RAM
> should be able to perform this task well.
Sorry. I have no idea on the performance metrics. The only thing I
have a (4+ year old) clue on is connection state and the conntrack
table. I don't even know how much of a problem that will be for you.
If this is a problem, it may be a rather large one as there is a
specific amount of memory that is needed per connection state. I guess
it will depend if each packet every 20 ms is considered a new connection
or not.
Like G.W. Haywood said, test it (or some smaller test) and see.
> Best Regards,
Likewise.
Grant. . . .
next prev parent reply other threads:[~2008-07-03 9:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-03 5:09 iptables resources consumed Elison Niven
2008-07-03 7:25 ` G.W. Haywood
2008-07-03 9:34 ` Grant Taylor [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-07-04 5:22 Elison Niven
2008-07-04 6:26 ` Grant Taylor
2008-07-04 9:12 ` re : " Elison Niven
2008-07-05 23:46 ` Grant Taylor
2008-07-07 5:32 ` Elison Niven
2008-07-07 15:04 ` Grant Taylor
2008-07-07 15:49 ` Grant Taylor
2008-07-02 4:29 Elison.Niven
2008-07-02 19:00 ` Grant Taylor
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=486C9D29.804@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--cc=netfilter@vger.kernel.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