You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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".
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.
The text was updated successfully, but these errors were encountered: