Date: Wed, 27 Sep 2000 10:26:16 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Patrick Bihan-Faou <patrick@mindstep.com> Cc: freebsd-net@freebsd.org Subject: Re: natd and userland ppp Message-ID: <Pine.BSF.4.10.10009271015390.15101-100000@InterJet.elischer.org> In-Reply-To: <128b01c028a3$e0f903d0$040aa8c0@local.mindstep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Sep 2000, Patrick Bihan-Faou wrote: > Hi, > > > > They are both running the same NAT library, but is you use NATD then the > > packet is diverted to userland TWICE, with it's > > attendant reduction in throughput and increase in latency.. > > This sounds like a fair reason. However it strikes me that there is quite a > bit of code duplication because of this: I know that libalias is used in > both, but you still need some support code in each one of them > (configuration elements etc.) + calling the actual aliasing code. well if you use the ppp nat then you don't call both sets of support code.. that's even more reason.. > > It seems also that some features (such as automatic holes in the firewall > and dynamic rules) are a bit tricky to get working properly with aliasing in > ppp. Now I probably missed some tricks on that side, so don't flame me > because of that last comment, educate me! I'm not an expert on PPP's filtering rules.. I'll let Brian answer that.. > > > > > PPP diverts packet out of the kernel once. Once it's diverted you might as > > well do the NAT on the packet. (and as I said, you'd have a lot of fun > > getting NATD synchronised with ppp. (You'd have to use all sorts of > > link-up and link-down scripts. > > > Well actually, with the "dynamic" option in natd, synchronizing to ppp is > really painless (or at least it looks like it is working properly). Thanks > to the magic of the routing socket. So this is hardly an argument. well, yes it works.. I'm not totally sure though if you can do everything quite the same. > > > > Mpd can use netgraph to do all ppp processing in the kernel to reduce > > latency even further, but it doesn't have NAT. You could however combine > > it with ipfilter's in-kernel NAT to get an all-kernel solution. > > (we need to make a netgraph NAT module but we haven't done it yet.) > > A netgraph nat module seems to be the way to go... As soon as I have some > spare time (wishfull thinking :) I'll look into that. yes I actually was considering using the NAT code from ipfilter to do the job.. the difficulty is deciding exactly wherre and how to slot a NAT module in.. if it were attached to an interface, then it would have to know about both IP and the MAC levels which would break layering. If it's attached to the IP stack (where ipfw presently gets packets for NAT from) then it loses some of the niceness of attaching it to an interface. Maybe it's not really a job for netgraph but a job for an IPFW keyword/Module. (then in that case we should look at ipfilter again as it isn't going away..) Personally I'd like a way of attaching a netgraph node between IP and the various interfaces. (I think this could be achieved by using the netgraph interface node as a frontend to the actual interfaces and not assigning IP addresses to the real interfaces you wanted to do NAT on, but instead assign those addresses to teh ng interfaces.. (hmmmm maybe..) > > > > So at this point, I take it that the main reason for not using natd with ppp > is because of the increased number of context switching between userland and > kernel code. > > > Patrick. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10009271015390.15101-100000>