ppp
ppp copied to clipboard
ppp-project
pppd as a LAC
https://lwn.net/Articles/833222/ refers.
Based on this it seems that the kernel has a mechanism to support pppoe bridging to l2tp.
We're running xl2tpd (with some patches I've already published on the project page) on our nodes already in LNS mode, but adding a LAC portion here is should be perfectly possible.
The question then becomes once pppd has received a connection, can we either by way of radius tag (not sure which tag would be appropriate, not seeing anything jump out when doing grep -i lac /usr/share/freeradius/dictionary*) or some other configuration (say lacmap) then kick over into LAC mode (ie, bridge between whatever incoming, pppoe and l2tp here).
Using radius would be preferred I reckon, as that allows us to control in a more fine-grained manner, however, lacmap may be simpler.
lacmap file may look something like:
realm lacname
And then somehow pppd needs to query xl2tp (or another l2tp daemon) to establish the relevant tunnel and obtain details for us to establish the bridge.
Not sure if this is viable, and insights would be appreciated. Will also dig further myself.
I'm not really that familiar with l2tp, so I don't know that I have much to add here until you get to the point of having pppd patches for review...
@paulusmack ok, so in an BNG scenario there is typically some switching environment at the FNO, end-users then create pppoe connections. The BNG picks up on te pppoe request, and based on the username in the authentication (specifically the realm portion thereof) then creates an l2tp tunnel between the BNG (A LAC from l2tp perspective) and the LNS. All the BNG does at this point is take ppp frames from the end user and forwards them to the LNS (ie, convert pppoe to l2tp) and vice versa.
The referenced link indicates that kernel support for this back-and-forth forwarding has been added, but userspace is still required to set up the relevant pppoe and l2tp sessions and tunnels.
I would need to investigate how one would go about establishing the relevant l2tp tunnels, possibly an external helper script scenario from pppd perspective, where said script will need to output the details that pppd requires to pass to the kernel, and again, to tear the tunnel down. This leaves the details of establishing and tearing down the l2tp tunnel outside the scope of ppp, but it doesn't make sense to build this in isolation on ppp side and hoping that somehow some l2tp setup would be achievable, so at a minimum I'd like to build a POC along with the relevant on ppp side.
My immediate need for this has gone away as suddenly as it has come forward. So whilst this is interesting to me it's not on my immediate agenda. I do suggest we leave this open as "future idea not for immediate implementation".
@nomis, @rfc1036, @zdzichu, @pali, @carlsonj, @masputra, @enaess, @chipitsine, @sthibaul, @alarig, @EasyNetDev, @anphsw, @dfskoll, @XWwalker, @kurt-vd, @nkukard, @kad, @tisj: What do you think?
Would this really belong to pppd? For instance, l2tpns https://code.ffdn.org/l2tpns/l2tpns/ does everything by itself, setting up the tunnels & sessions in the kernel for the kernel to handle data packet switching
Would this really belong to pppd? For instance, l2tpns https://code.ffdn.org/l2tpns/l2tpns/ does everything by itself, setting up the tunnels & sessions in the kernel for the kernel to handle data packet switching
Don't confuse a LAC and an LNS. LAC would bridge some variant of ppp (typically pppoe) on the incoming side to ppp/l2tp on the outgoing side.
I don't think this ticket deserves high priority.
Unless I missed a point, the LAC isn’t supposed to handle PPP, it only forwards L2TP to another LNS.
@alarig that's what makes this tricky ... PPP needs to be initiated in order to obtain the realm (typically) in order to determine which LNS to forward to, if any.
For example, let's say username in auth status is [email protected], then based on example.com we could decide that:
- This ppp should terminate locally and proceed as per current; or
- We don't handle this realm, create an L2TP tunnel to an LNS (selected based on the realm, so each realm could go to different LNS's), and shovel PPP frames back and forth between whatever is the incoming framing protocol, and L2TP.
It looks like there was some kernel support added for doing this relatively recently (referenced article, PPPoE <-> PPP/L2TP at least - which is the typical use-case) to bring Linux more up to spec with a "real" BNG.
It looks like there was some kernel support added for doing this relatively recently
Yes, tunnel switching was added in linux 5.11. l2tpns uses that support when it is available, for instance.
Look for "tunnel switching" in https://www.kernel.org/doc/html/latest/networking/l2tp.html#pppol2tp-session-socket-api
Would this really belong to pppd? For instance, l2tpns https://code.ffdn.org/l2tpns/l2tpns/ does everything by itself, setting up the tunnels & sessions in the kernel for the kernel to handle data packet switching
Don't confuse a LAC and an LNS. LAC would bridge some variant of ppp (typically pppoe) on the incoming side to ppp/l2tp on the outgoing side.
Well, sure, and?