On 28/09/16 00:08, Jonathan Morton wrote:
On 26 Sep, 2016, at 06:20, Kevin Darbyshire-Bryant
<[email protected]> wrote:
Another github user 'tegularius' presented some beautifully crafted
code that did the lookups in a much neater way. Originally it too
had an 'ingress' lookup problem. This was worked on and I hacked
some conditional 'denat' options into cake & tc.
For your 'delight' a denat cake
https://github.com/kdarbyshirebryant/sch_cake/tree/natoptions along
with a matching tc
https://github.com/kdarbyshirebryant/tc-adv/tree/denat
As I’m now at the stage of trying to merge this, I’m going to make
some executive design decisions:
- De-NAT IPv4 packets only. I think it’s safe to assume that IPv6
NAT will be rare, and in any case will typically preserve host
distinctions. This eliminates switch blocks in favour of simple if
blocks.
Agree completely. The IPv6 stuff was inherited/for completeness but
anyone doing many to one host masquerading with IPv6 really needs a slap!
- Don’t bother with the distinction between src-NAT and dst-NAT
lookups. The full lookup has to be done anyway and then masked off,
the use-case for the limited functionality is nebulous, and all we’re
doing is adding a lot of nasty conditional branches to the fast
path.
I winced at every condition as it was being put in believe me! It is
horrible and I think now is a left over from when I was trying to
understand how/why things weren't being translated as expected. I still
don't completely trust it, but that's what testing is for :-)
This in turn reduces the configuration interface for the feature to a
flag, which I’ll call “nat”.
Agreed.
Does this need to be another variable/parameter or could it be the next
bit along in the flow type?
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
