Bridge-nf and iptables SNAT

Bridge-nf and iptables SNAT

[Tsachi]

I have few questions regarding bridge-nf which I hope it is the right
place to ask:
Background: Embedded Linux MIPS 200 MHz, Kernel 2.6.35.12 (netfilter
iptables+ebtables)
I am developing a bridge device (2 ports) which receives an IP
(public) from the network (internet).
I want to share this IP between the bridge interface and the host
computer which is connected to one of the bridge port.
The bridge interface has a private IP (e.g 10.0.0.1) but when going
out to the internet it should use the public IP (which the host is
also using).

Host computer <-> device (bridge) <-> Internet

When "/proc/sys/net/bridge/bridge-nf-call-iptables" is enabled,
Adding a simple iptable SNAT postrouting  rule, works well.
SNAT perform on the bridge outbound packets and Inbound bridged
packets will be going through the iptable conntrack (NAT) flow and are
accepted by the bridged interface (if were initiated from it).
Packets from to the host are going through the bridge normally.

The problem is that enabling bridge-nf-call-iptables, has an effect on
bridge traffic throughput:
96Mb/s when disabled.
70Mb/s when enabled.

First question:
When I check the same without bridge (routing + SNAT) throughput was 86Mb/s.
When bridge-nf-call-iptables is enabled, packets are going through L2
bridge code as well as L3 netfilter code, but, why it has such an
effects on the throughput?

Second question:
In order to share an IP (with iptables SNAT, without enabling
bridge-nf-call-iptables) ,
One solution I thought about, is to write a new ebtable module (used
in the brouting chain) which looks for the packet in the conntrack.
In case it finds it, Drop (routed) the packet, thus going through the
iptables code, if not found - Accept it (bridged).
This means some skb header work and conntrack searching for every
packet, do you think is a good approach?

Is there something that I am missing and can be done in a simpler way?

Other ideas are very much welcome?


Thanks,

Kimel

Re: Bridge-nf and iptables SNAT

[Bart De Schuymer]

Op 18/06/2013 16:11, Tsachi schreef:
> The problem is that enabling bridge-nf-call-iptables, has an effect on
> bridge traffic throughput:
> 96Mb/s when disabled.
> 70Mb/s when enabled.
>
> First question:
> When I check the same without bridge (routing + SNAT) throughput was 86Mb/s.
> When bridge-nf-call-iptables is enabled, packets are going through L2
> bridge code as well as L3 netfilter code, but, why it has such an
> effects on the throughput?
I think to answer that will require performance profiling of the code, 
since as far as I know it's never happened.
Here are some thoughts:
- W.r.t. ebtables, the performance impact of let's say a FORWARD chain 
rule is bound to be higher for ebtables compared to iptables because it 
will be called more for the same traffic. Fragmented IP packets, f.e., 
will be processed one by one by the FORWARD chain (if 
bridge-nf-call-iptables is disabled) while an iptables FORWARD rule 
would only be called once. Flooded packets are seen multiple times by 
some ebtables chains (once for each output device). In the bridge-nf 
case, these flooded packets are also seen multiple time by some iptables 
chains.
- The function call stack is bigger in the bridge-nf compared to the 
standard iptables case because we have the combination of NF_HOOKs for 
NFPROTO_BRIDGE and NFPROTO_IPV4. NF_HOOK_THRESH adds to the equation. 
Note that due to the design of netfilter, the call stack can grow quite 
big because the NF_HOOK okfn is executed up the call stack.

> Second question:
> In order to share an IP (with iptables SNAT, without enabling
> bridge-nf-call-iptables) ,
> One solution I thought about, is to write a new ebtable module (used
> in the brouting chain) which looks for the packet in the conntrack.
> In case it finds it, Drop (routed) the packet, thus going through the
> iptables code, if not found - Accept it (bridged).
> This means some skb header work and conntrack searching for every
> packet, do you think is a good approach?
What you could also try is making something based on br_netfilter.c that 
only lets iptables connection tracking and POSTROUTING see the packets.
If you want full performance also for the traffic originating from the 
bridge, it's best if you do your magic using brouting: traffic that 
enters the IP stack through br0 is queued once more in the kernel than 
traffic that enters the IP stack through one of the bridge ports (by 
brouting the packet).

cheers,
Bart