On Mon, Apr 14, 2008 at 06:50:24PM -0700, Adam Richards wrote:
> And there's another nuance as well: on ingress I need dest
> re-mapped while preserving src,
Yes, that's how binat works.
> and on egress I need src re-mapped while passing on the [preserved]
> src as the egress dest.
I'm not sure I understand this bit. You want to reflect packets back to
the source? Or by "src" here you actually mean the "dst"? To be clear,
lets talk about this from the point of view of the ip header fields in
the packet, not the source of the connection. You want this to be
stateless, so we have to consider each packet independantly.
> > You're right, it should be relatively easy to give binat a 'no state'
> > option...
> >
> > But not for a /18 of arbitrary mappings with a high rate of change.
>
> I'm not so concerned with "arbitrary" mappings as I'll be
> statically configuring the mappings, maintaining them from
> outside pf.
By arbitrary, I meant "essentially random"
ie, You're not talking about mapping
10.29.4.0/18 to 192.168.64.0/18,
you're talking about
10.29.4.192 to 192.168.67.12
10.29.5.1 to 192.168.66.250
10.29.4.9 to 192.168.64.99
[ cut 2^14 examples ]
> To your last sentence, what if they're static mappings, ie - not
> arbitrary, with a high rate of change? ;)
With the current code, this will be super slow. Either you're reloading
entire rulesets, or managing 2^14 anchors. Lots of linked-list walking
involved.
> What happens in pf when a table has changed and pf need to
> re-read it? Will pkts get dropped?
Adding/removing single entries from a table is a /relatively/
inexpensive and atomic operation, but it involves some cost to cross
from userland to kernel. I imagine it can be pretty fast using a custom
tool rather than calling pfctl.
> > With the current translation code this would require a rule for
> > every mapping,
>
> This is how I plan on using pf -- 1:1 statically configured
> translations. IOW I don't care about free-floating addr pools.
Right. Although the free-floating pools might actually be easier to
implement.
> > and every packet is going to require a linear search of this
> > ruleset. Fixing this is going to require fairly major changes
> > to how binat works.
>
> Major changes, *if* we want binat to work with pools, right?
Well, tables. I have plans to remove the 'pools' bits from the pf
translation and routing code. It's basically a duplication of the tables
functionality.
> If it the core binat code remains unchanged, I'd guess modifying the
> search algorithm to be something as simple as a bubble sort, or maybe
> a radix tree implementation (as is common in networking code I
> believe), would be fairly easy to someone familiar with pf's
> inner-workings. I could be over-simplifying it.
radix tree implementation: that's what the tables are.
There are already some other optimizations in pf and pfctl that deal
with the ruleset, but they won't help too much case (dealing with a long
list of nearly-identical rules). There may be some ways to optimize
for this case, but I'm not sure it's worth the trouble. I'll have to
think about this more.
> > BTW: What kind of packet forwarding rate are you hoping to get with
> > this solution?
>
> To be on par with my Linux colleagues running the latest
> netfilter/iptables code I'd need to get >= 1Mpps on 10G links. Even
> though pkt sizes will obviously influence pps, most flows I deal with
> are rather short lived and contain, on avg, pkt sizes <= 512B. I
> expect to find predictible inflection points.
You will most certainly NOT get this with the current code, nor the diff
I've posted.
-Ryan
