Re: iptables resources consumed

Re: iptables resources consumed

[Elison Niven]

Hi,

I'd just like to clarify a few things I should have done before.

1) Eth0 and eth2 will always be in different subnets.
2) All RTP traffic that has to be sent to the DSPs will always arrive to
eth0.

> I'm concerned about traffic coming in eth0 going to the DSP connected to 
> eth2.  What IP do you send it to, the one being spoofed or the internal 
> one?  When the client send this traffic, will the reply come from the 
> same IP or will it be a different IP?  I see too much that could go 
> wrong in this that should not happen in normal traffic.

> *OR* is the IP spoofing not for the source IP of the packets leaving the 
> DSP but rather for an IP that is included as a value with in the payload 
> in the packet from the DSP, much like FTP packets include the port 
> number that they want to use or how you sometimes have to specify an 
> external IP for SIP VoIP devices behind a NAT.

Eth2 is an internal IP address. The system is known only by one IP address
to the outer world - that of eth0.

Consider an example: My System's IP is eth0 - 192.168.1.50, subnet mask -
255.255.255.0
Eth2 (internal) is 192.168.2.50, The DSPs are 192.168.2.51 to 192.168.2.58,
subnet mask - 255.255.255.0
The default gateway of the DSPs is eth2 - 192.168.2.50.

There is a voice call from another device at 192.168.1.100 to 192.168.1.50.

Outside the system, the following transfers are visible (say in
wireshark/ethereal):

192.168.1.100 --> Sends RTP:
src IP = 192.168.1.100
dest IP = 192.168.1.50
src port = 8000
dest port = 10000

My system 192.168.1.50 --> Sends RTP:
Src IP = 192.168.1.50
Dest IP = 192.168.1.100
Src port = 10000
Dest port = 8000

Inside the system, the RTP is actually generated by the DSPs, say DSP1 here.

DSP1 --> Sends RTP:
Src IP = 192.168.1.50 - This is IP spoofing. DSP1's actual IP is
192.168.2.51. This is the IP as seen in the source IP field in the IP
header.
Dest IP = 192.168.1.100
Src port = 10000
Dest port = 8000

This traffic is received on eth2 and must be sent out through eth0.
The purpose of faking the IP is not to have to do SNAT on such packets.

The traffic that the other device is sending is received on eth0.
Such traffic is forwarded to DSP1.

Each of the DSPs also sends control packets that are always sent as:

Src IP = DSPs actual IP address = 192.168.2.51
Dest IP = eth2 = 192.168.2.50

Such packets need to be sent to a local process on the CPU.

So I guess the minimal rules needed will be:

1) For packets received on interface eth2

IF Destination IP != eth2 IP
THEN send the packet out from eth0
ELSE send it to the CPU

2) For packets received on interface eth0

Now the system will be listening for http, telnet and ftp connections on
their fixed port numbers.
The system will also be listening for SIP connections to a fixed port - say
5060.
Such packets obviously need to be sent to the CPU.
Does that mean I have to check the destination port number of all the
packets received?

IF Dest port of packet == 80 (http) OR 21(ftp) OR 23(telnet) OR 5060(sip).
(Does this becomes a single rule or more than one?)
THEN send packet to the CPU
ELSE goto below rules

For all other packets received, the rule will be (for the example above):

IF Source IP == 192.168.1.100 and destination port == 10000. Again does this
become 2 different rules?
If I also check the source port of the packet here, will that add a new
rule?
THEN send the packet to DSP1. This will require a DNAT I think.
ELSE drop the packet.

Now I intend to (horribly) support 256 such calls and I need to figure out
the minimal rules that would be required.

(Ofcourse, I see above that there would be some (don't know how many)
problems when an external device with IP = 192.168.2.51 wants to talk to my
system, But we'll get to it later.)

Best Regards,
Elison

Re: iptables resources consumed

[Grant Taylor]

On 7/4/2008 12:22 AM, Elison Niven wrote:
> I'd just like to clarify a few things I should have done before.
> 
> 1) Eth0 and eth2 will always be in different subnets.

Ok.

> 2) All RTP traffic that has to be sent to the DSPs will always arrive 
> to eth0.

Ok.

> Eth2 is an internal IP address. The system is known only by one IP 
> address to the outer world - that of eth0.

*nod*

> Consider an example: My System's IP is eth0 - 192.168.1.50, subnet 
> mask - 255.255.255.0 Eth2 (internal) is 192.168.2.50, The DSPs are 
> 192.168.2.51 to 192.168.2.58, subnet mask - 255.255.255.0 The default 
> gateway of the DSPs is eth2 - 192.168.2.50.

This is simple enough.

> There is a voice call from another device at 192.168.1.100 to 
> 192.168.1.50.
> 
> Outside the system, the following transfers are visible (say in 
> wireshark/ethereal):
> 
> 192.168.1.100 --> Sends RTP:
> src IP = 192.168.1.100
> dest IP = 192.168.1.50
> src port = 8000
> dest port = 10000
> 
> My system 192.168.1.50 --> Sends RTP:
> Src IP = 192.168.1.50
> Dest IP = 192.168.1.100
> Src port = 10000
> Dest port = 8000

Ok.  This is the request and the reply (if you will) as seen when 
sniffing the cable connected to eth0 of your system.

> Inside the system, the RTP is actually generated by the DSPs, say 
> DSP1 here.
> 
> DSP1 --> Sends RTP:
> Src IP = 192.168.1.50 - This is IP spoofing. DSP1's actual IP is 
> 192.168.2.51. This is the IP as seen in the source IP field in the IP 
> header.
> Dest IP = 192.168.1.100
> Src port = 10000
> Dest port = 8000
> 
> This traffic is received on eth2 and must be sent out through eth0. 
> The purpose of faking the IP is not to have to do SNAT on such 
> packets.

You can do the source IP spoofing here, but I would not recommend it for 
multiple reasons.
  - You will have to (re)configure all the DSPs with the IP of eth0 if 
it ever changes.
  - This could conflict with reverse path filtering on your system.
  - IMHO this is bad form.
  - If the DSP wants to communicate with your system it will have to use 
a different source IP, or other trickery will have to be done to allow 
your system to communicate with the DSP.
  - SNATing is not going to be that much of a load.

> The traffic that the other device is sending is received on eth0. 
> Such traffic is forwarded to DSP1.

Ok.

> Each of the DSPs also sends control packets that are always sent as:
> 
> Src IP = DSPs actual IP address = 192.168.2.51 Dest IP = eth2 = 
> 192.168.2.50

Ok.

> Such packets need to be sent to a local process on the CPU.

By standard routing and socket binding this will be inherent.

> So I guess the minimal rules needed will be:
> 
> 1) For packets received on interface eth2
> 
> IF Destination IP != eth2 IP THEN send the packet out from eth0 ELSE 
> send it to the CPU

This is not a rule.  This is standard routing / forwarding.  If a packet 
coming in to an interface has a destination IP belonging to the system, 
it will be processed by the system.  If a packet coming in to an 
interface has a destination that does not belong to the system it will 
be forwarded as long as forwarding is enabled.

> 2) For packets received on interface eth0
> 
> Now the system will be listening for http, telnet and ftp connections 
> on their fixed port numbers. The system will also be listening for 
> SIP connections to a fixed port - say 5060. Such packets obviously 
> need to be sent to the CPU. Does that mean I have to check the 
> destination port number of all the packets received?
> 
> IF Dest port of packet == 80 (http) OR 21(ftp) OR 23(telnet) OR 
> 5060(sip). (Does this becomes a single rule or more than one?) THEN 
> send packet to the CPU ELSE goto below rules

No.  Again, any packets coming in with a destination IP belonging to the 
system will be passed up in to the system for processing.

> For all other packets received, the rule will be (for the example 
> above):
> 
> IF Source IP == 192.168.1.100 and destination port == 10000. Again 
> does this become 2 different rules? If I also check the source port 
> of the packet here, will that add a new rule? THEN send the packet to 
> DSP1. This will require a DNAT I think. ELSE drop the packet.

This is one rule with multiple conditions to it.  If this or other rules 
are not matched, have a final rule or chain default policy to drop the 
packet.

> Now I intend to (horribly) support 256 such calls and I need to 
> figure out the minimal rules that would be required.

Can you provide a list of source / destination IPs and ports or a 
pattern there of?  I'll look at it and see how many rules I think would 
be needed (with and with out the optimizations that I spoke of).

> (Ofcourse, I see above that there would be some (don't know how many) 
> problems when an external device with IP = 192.168.2.51 wants to talk 
> to my system, But we'll get to it later.)

Heh.  This is another reason why I suggest that you not have your 
external IP configured on the DSPs because if you need to change it, you 
will have to change configs on your DSPs too.

Now this brings up a question as to whether this is a config for a 
specific install or if this is to be more dynamic and installed a bunch 
of places.  If it is the former corners can be cut, but if it is the 
later, care should be taken to take these types of things in to account.



Grant. . . .

re : iptables resources consumed

[Elison Niven]

Hi,

Comments inline.

> You can do the source IP spoofing here, but I would not recommend it for 
> multiple reasons.
>   - You will have to (re)configure all the DSPs with the IP of eth0 if 
> it ever changes.
>   - This could conflict with reverse path filtering on your system.
>   - IMHO this is bad form.
>   - If the DSP wants to communicate with your system it will have to use 
> a different source IP, or other trickery will have to be done to allow 
> your system to communicate with the DSP.
>   - SNATing is not going to be that much of a load.

Well, this is not a problem at all. The source IP that the DSP puts in the
*RTP packets* it generates can be changed dynamically at runtime. And it can
be different for different RTP sessions as well, not that I would need to do
it. That apart, this is allowed only for *RTP packets* (this traffic has to
forwarded out from eth0). All other packets (the only ones that remain are
the DSP control packets directed towards my system) use the source IP as the
actual DSP IP address.

> This is not a rule.  This is standard routing / forwarding.  If a packet 
> coming in to an interface has a destination IP belonging to the system, 
> it will be processed by the system.  If a packet coming in to an 
> interface has a destination that does not belong to the system it will 
> be forwarded as long as forwarding is enabled.

Ok, but all the packets that I need to send to the DSPs will reach my system
and will have destination IP belonging to my system. They are not needed to
be processed by my system but are to be sent to the DSPs. How do I do that?

> Can you provide a list of source / destination IPs and ports or a 
> pattern there of?  I'll look at it and see how many rules I think would 
> be needed (with and with out the optimizations that I spoke of).

Well, actually this list is dynamic and can change at runtime. The actual
port numbers and IP addresses depend on the SIP/SDP negotiation.

Thanks a lot for helping me out.

Best regards,
Elison

Re: re : iptables resources consumed

[Grant Taylor]

On 7/4/2008 4:12 AM, Elison Niven wrote:
> Well, this is not a problem at all. The source IP that the DSP puts 
> in the *RTP packets* it generates can be changed dynamically at 
> runtime. And it can be different for different RTP sessions as well, 
> not that I would need to do it. That apart, this is allowed only for 
> *RTP packets* (this traffic has to forwarded out from eth0). All 
> other packets (the only ones that remain are the DSP control packets 
> directed towards my system) use the source IP as the actual DSP IP 
> address.

Ok.  The, I suppose you can spoof the source IP if you want to.

> Ok, but all the packets that I need to send to the DSPs will reach my 
> system and will have destination IP belonging to my system. They are 
> not needed to be processed by my system but are to be sent to the 
> DSPs. How do I do that?

Right, this is why you DNAT them to the DSPs inside.

> Well, actually this list is dynamic and can change at runtime. The 
> actual port numbers and IP addresses depend on the SIP/SDP 
> negotiation.

Uh, this could make for a bit of fun.  It is trivial to write an 
IPTables rule to match based on static source / destination IP and / or 
source / destination port or any combination there of.  However to match 
the dynamic ports, you will need may need a helper to find what is 
negotiated.

Question:  Is filtering out packets from the DSPs other than what you 
have mentioned a must or is it ok if packets leak out.  In other words, 
do they have to be filtered (prevent them from going) out as long as the 
RTP packets go where they are suppose to go?

> Thanks a lot for helping me out.

*nod*  You are welcome.



Grant. . . .

Re: iptables resources consumed

[Elison Niven]

Hi,

> Uh, this could make for a bit of fun.  It is trivial to write an 
> IPTables rule to match based on static source / destination IP and / or 
> source / destination port or any combination there of.  However to match 
> the dynamic ports, you will need may need a helper to find what is 
> negotiated.

My main application will know these IP addresses and port numbers through
the negotiation. Once the negotiation is done actual RTP data will flow to
and from the DSPs and this data has to sent from eth0 to eth2 and from eth2
to eth0.

After the negotiation, my main application (in C) will do a simple system
call like

system("iptables [OPTIONS] ...");

to add a rule for packets received on eth0 and on which DSP to forward them
to.

After the call is over, my main application will do another call to iptables
to remove the above added rule.

> Question:  Is filtering out packets from the DSPs other than what you 
> have mentioned a must or is it ok if packets leak out.  In other words, 
> do they have to be filtered (prevent them from going) out as long as the 
> RTP packets go where they are suppose to go?

No, packets that the DSPs send are not to be prevented from going out on
eth0.

Best Regards,
Elison

Re: iptables resources consumed

[Grant Taylor]

On 07/07/08 00:32, Elison Niven wrote:
> Hi,

Morning.

> My main application will know these IP addresses and port numbers 
> through the negotiation. Once the negotiation is done actual RTP data 
> will flow to and from the DSPs and this data has to sent from eth0 to 
> eth2 and from eth2 to eth0.

Ok...

> After the negotiation, my main application (in C) will do a simple 
> system call like
> 
> system("iptables [OPTIONS] ...");
> 
> to add a rule for packets received on eth0 and on which DSP to 
> forward them to.

Ah.  So you do not want to put these rules (that we have been 
discussing) in a system start up script / iptables-save file.  This 
makes things a bit more interesting in the long run.  (See below.)

> After the call is over, my main application will do another call to 
> iptables to remove the above added rule.

Having IPTables rules programmatically removed can be a bit tricky in 
such as having your code know what rule to remove from the list of 
rules.  I suggest that you either use sub-chains and have your code 
flush flush the sub-chain(s), or use the "comment" extension to tag the 
rules, or attempt to pass the exact rule to iptables again to have it 
delete the rule(s) in question.  I personally find the sub-chain to be 
more consistent and less error prone.

Also, you may want to search the archives about having C programs use 
API calls to modify the IPTables chains.

> No, packets that the DSPs send are not to be prevented from going out 
> on eth0.

Ok.



Grant. . . .

Re: iptables resources consumed

[Grant Taylor]

On 07/07/08 00:32, Elison Niven wrote:
> My main application will know these IP addresses and port numbers 
> through the negotiation. Once the negotiation is done actual RTP data 
> will flow to and from the DSPs and this data has to sent from eth0 to 
> eth2 and from eth2 to eth0.

Ok.  So let's think about this with the forwarding of RTP packets 
prohibited (DROPed) until your application allows (sets up DNATing) of 
the packets.  What will happen, how will things respond, if the first 
(few?) RTP packets get dropped / rejected before the DNATing is enabled?

Presuming that the possibility of the first (few) RTP packets being 
dropped is ok, I would do the following:
  - All only the inbound traffic that you want (SSH, HTTP, NTP, etc.).
  - Block all inbound to be processed traffic by default.
  - Block all inbound to be forwarded traffic by default.
  - Block all outbound to be forwarded traffic by default.
  - Have your control program dynamically update the NATing rules to 
forward traffic you want.
  - Have your control program dynamically update the forwarding rules to 
allow the NATed traffic to be forwarded.

> After the call is over, my main application will do another call to 
> iptables to remove the above added rule.

*nod*

> No, packets that the DSPs send are not to be prevented from going out 
> on eth0.

Ok.

This sounds like it will be much easier to set things up to block (DROP) 
all forwarded traffic by default and set up exceptions for what you do 
want forwarded and / or allow inbound for (local) processing.

iptables -t filter -P INPUT DROP
iptables -t filter -A INPUT -i eth2 -j ACCEPT
iptables -t filter -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -t filter -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
...

iptables -t filter -P FORWARD DROP
iptables -t filter -A FORWARD -i eth0 -o eth2 -d <DSP1> -p udp --dport 
8000 -j ACCEPT
iptables -t filter -A FORWARD -i eth2 -o eth0 -p udp --sport 8000 -j ACCEPT
...

iptables -t nat -A PREROUTING -i eth0 -d <eth0 IP> -p udp --dport 8000 
-j DNAT --to-destination <DSP1>
...

Something to consider.  With your control program dynamically adjusting 
the rules, you may not need to monitor packet state.  So if you can set 
up NATing with out connection tracking, you will have less load on your 
kernel.  However I don't know if you can do NATing with out connection 
tracking being in the kernel as I always have needed connection 
tracking.  If you do have to have connection tracking, you may be able 
to use the RAW table and it's NOTRACK target to avoid the connection 
tracking overhead.  Some experimentation will say for sure.  Or, perhaps 
someone else will help clarify this.



Grant. . . .

Re: iptables resources consumed

[Elison Niven]

Hi, 

Grant - Thanks a lot for your reply. 

>Question:  What do you want to do with packets that do not match the 
>above rules?
I would just like to discard them.

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.

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.

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.

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.

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.

Please correct me if I am missing something.

>>There will be a lot of traffic flying through this kernel.

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.

Best Regards,
Elison

Re: iptables resources consumed

[G.W. Haywood]

Hi there,

On Thu, 3 Jul 2008, Elison Niven wrote:

> Do you a think a custom powerc kernel running at 400 MHx,256 MB DDR2
> RAM should be able to perform this task well.

I think you're just going to have to try it and see.

Have you seen this?

http://people.netfilter.org/kadlec/nftest.pdf

I got 44,000 hits from Google for the search

iptables performance powerpc

--

73,
Ged.

Re: iptables resources consumed

[Grant Taylor]

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

iptables resources consumed

[Elison.Niven]

Hi List,

I am looking to run iptables on an embedded powerpc system.
It’s the first time I’ll be using it. I need to have a few confusions cleared out.

There are three ethernet interfaces on the system: eth0, eth1 and eth2.
___________________________________
|                                  |
|         ___________              |
|        |           |             |
|        |  Powerpc  |             |
|        |           eth2          |
|        |           |             |
|        |_eth0_eth1_|             |
|                                  |
|       _______        ________    |
|_______|      |_______|       |___|
         eth0           eth1

eth0 and eth1 are external interfaces to the system. eth2 is internal.
eth2 is connected to another L2 switch on the same board behind which are 8 DSPs.

For now do not consider eth1. There are only 2 interfaces eth0 and eth2.

I need to forward UDP packets received on eth0 to eth2 and send them to a particular DSP, and also forward packets received on eth2 to eth0.

General rule: All outgoing packets from eth0 should have src ip = eth0 ip.

Example rules:

Rule 1: a)Packets received on eth0 with src IP address = X, dest port = 8000 should be sent to DSP1, port = 8000.
b)Packets received on eth2 (i.e from the L2switch) with src IP = DSP1 IP OR dest IP = X, dest port = 10000 should be sent on eth0 to IP address X, port = 10000.

Rule 2: a)Packets received on eth0 with src IP address = Y, dest port = 9000 should be sent to DSP2, port = 9000.
b)Packets received on eth2 (i.e from the L2switch) with src ip = DSP2 IP OR dest IP = Y, dest port = 11000 should be sent on eth0 to IP address Y, port = 11000.

I will have a maximum of 256 such rules i.e effectively 256*2 = 512 rules. (256 for packets received on eth0, 256 for packets received on eth2)

I am assuming that a packet is received every 20 ms on eth0 and eth2 for a single rule.
So for a total of 256, 256 packets are received every 20 ms on eth0 and 256 packets are received every 20 ms on eth2.

Or I can make eth2 IP address as the default gateway of all the DSPs. The DSPs will send packets with dest IP address = X, Y etc. These packets should be sent out through eth0 and should have source IP = eth0. This will eliminate rules 1b and 2b above. Thus, packet filtering to read src IP and dest port will only be on eth0. Now total rules will be 256.

The processor will be running at 400 MHz, 256 MB DDR2 RAM using Linux kernel 2.6.10.

Will it be able to do this task and also run the main application? How much resources will iptables require?

Regards,
Elison

Re: iptables resources consumed

[Grant Taylor]

On 07/01/08 23:29, Elison.Niven@matrixtelesol.com wrote:
> I need to forward UDP packets received on eth0 to eth2 and send them 
> to a particular DSP, and also forward packets received on eth2 to 
> eth0.

That in and of its self should not be a problem.

Question:  Do you either want or need globally routable IPs on the DSPs, 
or would you prefer to have private IPs?

I ask because at this point, you can either use IPTables / NATing / 
routing or you could use EBTables and bridging to do what you are 
wanting to do.

> General rule: All outgoing packets from eth0 should have src ip = 
> eth0 ip.

Ok.  This is the first implication that you will be using different IPs 
internally and want everything externally to be seen as one IP.  This 
indicates that you will probably be using internal IPs and IPTables.

> Example rules:
> 
> Rule 1:
> 
> a) Packets received on eth0 with src IP address = X, dest port = 8000 
> should be sent to DSP1, port = 8000.
> 
> b) Packets received on eth2 (i.e from the L2switch) with src IP = DSP1 
> IP OR dest IP = X, dest port = 10000 should be sent on eth0 to IP 
> address X, port = 10000.
> 
> Rule 2:
> 
> a) Packets received on eth0 with src IP address = Y, dest port = 9000 
> should be sent to DSP2, port = 9000.
> 
> b) Packets received on eth2 (i.e from the L2switch) with src ip = DSP2 
> IP OR dest IP = Y, dest port = 11000 should be sent on eth0 to IP 
> address Y, port = 11000.

Ok.

> I will have a maximum of 256 such rules i.e effectively 256*2 = 512 
> rules. (256 for packets received on eth0, 256 for packets received on 
> eth2)

Eh, yes and no.  You really have three rules per "Rule <#>:" above.

  - Packets coming in eth0 with a source IP of X with a destination port 
of 8000 should be sent to destination IP of DSP1 and destination port 8000.
  - Packets coming in eth2 with a source IP of DSP1 with a destination 
port of 10000 should be sent with a source IP of eth0 and a destination 
port of 10000.
  - Packets coming in eth2 with a destination IP of X with a destination 
port of 10000 should be sent with a source IP of eth0 and a destination 
port of 10000.

The "OR" really makes two rules for "b)".  So you will have apparently 
256 sets of these 3 rules for at minimum a total of 768 rules.  I think 
some careful planning needs to be done when creating your rule set(s). I 
think I'd start with a simple structure like this:

Put the following rules in your PREROUTING chain.
  - If the packet is coming in eth0 go to a subchain "in_eth0".
  - If the packet is coming in eth2 go to a subchain "in_eth2".

Put the following rules in your "in_eth0" chain.
  - If source IP is X and the destination port is 8000 go to a subchain 
"in_DSP1".
  - If source IP is Y and the destination port is 9000 go to a subchain 
"in_DSP2".
  - etc.
    (There is room for a tree structure to optimize the number of rules 
that have to be tested before a match is found.)

Put the following rules in your "in_eth2" chain.
  - If source IP is DSP1 and the destination port is 10000 go to a 
subchain of "out_DSP1".
  - If destination IP is X and the destination port is 10000 go to a 
subchain of "out_DSP1".
  - If source IP is DSP2 and the destination port is 11000 go to a 
subchain of "out_DSP2".
  - If destination IP is X and the destination port is 11000 go to a 
subchain of "out_DSP2".
    (There is room for a tree structure to optimize the number of rules 
that have to be tested before a match is found.)

Put the following rule in your "in_DSP1" chain.
  - DNAT to destination IP of DSP1 and destination port 8000.

Put the following rule in your "in_DSP2" chain.
  - DNAT to the destination IP of DSP2 and the destination port 9000.

Put the following rule in your "out_DSP1" chain.
  - SNAT to the source IP of eth0 with a destination port of 10000.

Put the following rule in your "out_DSP2" chain.
  - SNAT to the source IP of eth0 with a destination port of 11000.

This is a fairly loose and expandable structure.  I'm jumping to sub 
chains where arguable I could put the two chains together.  I could do 
the NATing (that is being done in "in_DSP1") in the "in_eth0" chain. 
However if you want to add an "OR" condition, you would have duplication 
in the "in_eth0" chain.  So I'm leaving room to grow with out having to 
duplicate.  Besides, this is also more consistent with what is being 
done in "in_eth2" having multiple rules jumping to the "out_DSP<#>" chains.

The main performance problem that I see is the "in_eth0" and "in_eth2" 
chains will be sizable and have quite a few rules in them.  I think this 
could possibly be broken down in to sub-chains to reduce the maximum 
number of rules that have to be checked before finding one that matches.

This method may seem like it is a lot more complex than hundreds or 
thousands of rules in a single chain, but it will seriously reduce the 
number of check that the kernel has to perform on each and every packet. 
  Think about how many rules the kernel would have to process in worst 
case for the packets that are the last to be matched.  This is where 
this optimization comes in to play.  In a way this could be sort of like 
trying to create a balanced tree structure for the rules, something that 
databases and file systems try to do to make it easy (read: faster) to 
find files.

Question:  What do you want to do with packets that do not match the 
above rules?

> I am assuming that a packet is received every 20 ms on eth0 and eth2 
> for a single rule.

So minimizing the number of rules that have to be checked against will 
dramatically help the performance of the system.

I take it that all DSPs will (normally) have a packet every 20 ms, so 
there is no re-arranging the rules in a given chain to move the most 
frequently matched to the start of the chain.

> So for a total of 256, 256 packets are received every 20 ms on eth0 
> and 256 packets are received every 20 ms on eth2.

*nod*

There will be a lot of traffic flying through this kernel.

> Or I can make eth2 IP address as the default gateway of all the DSPs. 
> The DSPs will send packets with dest IP address = X, Y etc. These 
> packets should be sent out through eth0 and should have source IP = 
> eth0. This will eliminate rules 1b and 2b above. Thus, packet 
> filtering to read src IP and dest port will only be on eth0. Now 
> total rules will be 256.

As long as you are sending the packets back out to the world with the 
proper source and / or destination port, yes, you could reduce your 
number of rules (by not having rules to match outgoing packets).  You 
will still need to SNAT / MASQUERADE the traffic, but that can be a 
single rule.

> The processor will be running at 400 MHz, 256 MB DDR2 RAM using Linux 
> kernel 2.6.10.

Ok...  I've never worked with a RISC based processor on a firewall, 
theoretically it will perform better than a CISC.  However you need to 
make sure that things are compiled for the level of processor you are 
using.  Do *NOT* use a generic kernel for any PowerPC.  Make sure you 
compile one for *your* PowerPC so that you are taking advantage of all 
the optimizations that it can provide.

> Will it be able to do this task and also run the main application? 
> How much resources will iptables require?

Comparing 256 packets against 256 rules every is 65536 comparisons every 
20 ms.  I don't know how much CPU time that will take, but I can see how 
there is a possibility of a problem.  Using a tree I can guarantee the 
worse case scenario to match 1 of 256 possibilities with in 16 
comparisons (best case is 4, worst case is 16).  This will be *much* 
easier on a processor than having to match worse case 256 rules per 
packet (best case is 1, worst case is 256).



Grant. . . .