I believe you'd be better off starting with rp-l2tp and hacking that. In my experience (I'm the author of rp-l2tp, of course! :-)) it's more reliable than l2tpd.
Yeah, I'll be looking at rp-l2tp over the weekend. Just finding the latest source for l2tpd-0.69 was hard enough.
Google's not what it used to be.
You will not easily achieve that with the current Linux PPP implementation. On our tests on a real-world machine running rp-l2tp, each PPP connection took approximately 1MB (!), so you'd need a lot of RAM to accomodate 2000 of them.
I expect that PPP isn't being particularly careful about memory, and that there's a lot of cruft to be trimmed out of that 1MB (we saw about 100k in shared, 800k/process). Stuff like handling modem control lines and negotiating compression, for example - neither of which is compatible or required for PPP over L2TP.
> Also, as you mentioned, the > context-switching of 2000 userspace processes will be hard on the CPU.
Perhaps one day "we" ("someone") can look at a different PPP implementation which handles all the interfaces through one daemon (a "virtual Cisco"). I'd want to do it in a way that can take advantage of the Linux iptables and traffic shaping capabilities.
Reworking it to do so will be a lot of work.
But fun!
And from what I've seen, someone has already started some of the work: http://l2tpd.graffl.net/msg00639.html
Though I'm not sure what the 100 limit is about: http://l2tpd.graffl.net/msg00638.html
Is that as far as the kernel will search for an unused PPP device? If I can get PPP to read peers files for incoming connections, I could allocate the interface based on the IP address (eg: address 1.2.3.20 would get ppp20, 1.2.3.234 would get ppp234).
Then I'll have to figure out how to deal with an ifconfig output that is 50 screens long...
Something like this: http://l2tpd.graffl.net/msg00642.html
Would be nice - but for traffic shaping purposes, wouldn't we need to have 1 interface per IP?
Actually, no we wouldn't... just use a separate IMQ for each set of IPs that are being specially shaped, to emulate the per-interface queues that would otherwise have been available.
time to get back to the real work...
Alex Satrapa
