- add network namespace support. Recent kernels allow interfaces to be associated with a network namespace. Traffic cannot pass between namespaces and the address space is independent. This allows arbitrary L2TP sessions to be grouped together, completely independent of other users on the same system. This usage is often referred to as a "walled garden". The currently unused priv_group_id session parameter will be used to identify the network namespace to which the session's interface will be assigned.
Sounds interesting. I've been trying to follow the recent work on namespaces but I'm left confused about how it is going to work with tunnel devices such as L2TP and GRE. Is it possible for tunnel drivers to have their virtual devices in different namespaces to which they sends/receives the tunnel packets? What little documentation I've found on the namespaces suggests rather more isolation.
Which namespace would the pppd's themselves be running under? If they were in the private namespaces they wouldn't be able to talk to the RADIUS server, etc.
Currently we fake up separate namespaces on our LNSs with a fwmark based routing policy, multiple routing tables, stateless firewall rules, a few kernel patches (to preserve the fwmark when generating ICMP and checking RP filter) and a fairly extensive patch to Quagga. It would be really nice to be able do away with all that and have the kernel handle it properly.
I don't think configuring the namespace in the openl2tp session parameters is going to meet our requirements. As I imagine is the case with many other ISPs our incoming sessions all come from the same pool of LTS at the wholesale provider and until we've authenticated the PPP sessions we are unable to identify which namespace the session belongs in. Is it feasible to switch namespace from the pppd after RADIUS authentication?