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