Using PPP networking under Linux

Benjamin LaHaise | 8 Jul 2012 23:49

[RFC PATCH] ppp: add support for L2 multihop / tunnel switching

Hello folks,

Below is a first cut at implementing multihop L2TP, also known as tunnel 
switching.  The feature is similar in scope to how PPPoE relaying works -- 
L2 packets that are received on one PPP interface are forwarded to another.  
This feature is typically used for traffic aggregation and backhaul for 
ISPs, with incoming sessions (often PPPoE) being partially authenticated 
by a LAC, and then forwarded over an L2TP session to an LNS (selected by the 
user's domain) which then provides network access to the client.

This is an RFC primarily to get some feedback on the implementation 
approach being used.  At present, this code is intercepting packets as soon 
as they are received on a PPP channel.  The packets are then modified to 
use a fake ETH_P_PPP protocol type and sent out over another PPP device 
via dev_queue_xmit().  In theory this enables forwarding of any type of PPP 
session, although I've only tested L2TPv2 so far.

The reasoning behind using dev_queue_xmit() rather than outputting directly 
to another PPP channel is to enable the use of the traffic shaping and 
queuing features of the kernel on multihop sessions.

Comments / thoughts?  A sample test program is available at 
http://www.kvack.org/~bcrl/pppol2tp/multihop.c .  I am in the process of 
updating the Babylon PPP implementation to use this functionality, and 
expect to be ready to make those changes available later this week.  I 
have not yet finished testing this code, so I'm sure that there are bugs 
lurking within.

		-ben

(Continue reading)

headers

James Chapman | 9 Jul 2012 13:52

Re: [RFC PATCH] ppp: add support for L2 multihop / tunnel switching

On 08/07/12 22:49, Benjamin LaHaise wrote:
> Hello folks,
> 
> Below is a first cut at implementing multihop L2TP, also known as tunnel 
> switching.  The feature is similar in scope to how PPPoE relaying works -- 
> L2 packets that are received on one PPP interface are forwarded to another.  
> This feature is typically used for traffic aggregation and backhaul for 
> ISPs, with incoming sessions (often PPPoE) being partially authenticated 
> by a LAC, and then forwarded over an L2TP session to an LNS (selected by the 
> user's domain) which then provides network access to the client.

As a mechanism for switching PPP interfaces together, this patch is
good. For L2TP though, I prefer an approach that would be applicable for
all L2TP traffic types, not just PPP.

L2TP supports many different pseudowire types, and this patch will only
be useful for tunnel switching between PPP pseudowires. Whereas if we
implement it within the L2TP core, rather than in the PPP code, we would
get switching between all pseudowire types. If we add this patch and
then subsequently add switching between other pseudowires in the L2TP
core (which we're likely to want to do), then we're left with two
different interfaces for doing L2TP tunnel switching in the kernel.

The L2TP core allows traffic to be passed directly into an L2TP session.
In the case of PPPoE, for example, the PPP data can be  extracted from a
PPPoE packet and passed into an L2TP tunnel/session, with no PPP
interface(s) involved.

That said, your approach allows two PPP interfaces to be switched
together, which has its own advantages.

(Continue reading)

headers

Benjamin LaHaise | 9 Jul 2012 16:15

Re: [RFC PATCH] ppp: add support for L2 multihop / tunnel switching

On Mon, Jul 09, 2012 at 12:52:15PM +0100, James Chapman wrote:
> As a mechanism for switching PPP interfaces together, this patch is
> good. For L2TP though, I prefer an approach that would be applicable for
> all L2TP traffic types, not just PPP.

*nod*  This seems like a reasonable consideration.

> L2TP supports many different pseudowire types, and this patch will only
> be useful for tunnel switching between PPP pseudowires. Whereas if we
> implement it within the L2TP core, rather than in the PPP code, we would
> get switching between all pseudowire types. If we add this patch and
> then subsequently add switching between other pseudowires in the L2TP
> core (which we're likely to want to do), then we're left with two
> different interfaces for doing L2TP tunnel switching in the kernel.

At least for ethernet pseudowires, it can already be implemented by using 
an ethernet bridge device.  Besides PPP and ethernet pseudowires, what 
other types are supported at present by the L2TP core?

> The L2TP core allows traffic to be passed directly into an L2TP session.
> In the case of PPPoE, for example, the PPP data can be  extracted from a
> PPPoE packet and passed into an L2TP tunnel/session, with no PPP
> interface(s) involved.
> 
> That said, your approach allows two PPP interfaces to be switched
> together, which has its own advantages.

I think the approach I'm using should be reasonably efficient for PPPoE 
to L2TP, although the locking overhead in the PPP core probably needs to 
be reduced to improve scaling.  I haven't yet done any benchmarking on this

(Continue reading)

headers

Benjamin LaHaise | 10 Jul 2012 05:27

[RFC PATCH v2 net-next] Re: [RFC PATCH] ppp: add support for L2 multihop / tunnel switching

Hello all,

Here is v2 of the PPP multihop patch.  This version adds a notifier hook to 
make sure that the multihop reference is dropped when the multihop target 
gets unregistered, ensuring that the references are properly dropped witout 
leaking the devices.

		-ben

Not-yet-signed-off-by: Benjamin LaHaise <bcrl <at> kvack.org>
 drivers/net/ppp/ppp_generic.c |  119 ++++++++++++++++++++++++++++++++++++++++--
 include/linux/if_ether.h      |    1 
 include/linux/ppp-ioctl.h     |    1 
 3 files changed, 118 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 5c05572..6dc7eff 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
 <at>  <at>  -121,6 +121,7  <at>  <at>  struct ppp {
 	unsigned long	last_xmit;	/* jiffies when last pkt sent 9c */
 	unsigned long	last_recv;	/* jiffies when last pkt rcvd a0 */
 	struct net_device *dev;		/* network interface device a4 */
+	struct net_device *multihop_if;	/* if to forward incoming frames to */
 	int		closing;	/* is device closing down? a8 */
 #ifdef CONFIG_PPP_MULTILINK
 	int		nxchan;		/* next channel to send something on */
 <at>  <at>  -272,6 +273,7  <at>  <at>  static void unit_put(struct idr *p, int n);
 static void *unit_find(struct idr *p, int n);

(Continue reading)

headers

James Chapman | 10 Jul 2012 11:32

Re: [RFC PATCH] ppp: add support for L2 multihop / tunnel switching

On 09/07/12 15:15, Benjamin LaHaise wrote:
> On Mon, Jul 09, 2012 at 12:52:15PM +0100, James Chapman wrote:
>> As a mechanism for switching PPP interfaces together, this patch is
>> good. For L2TP though, I prefer an approach that would be applicable for
>> all L2TP traffic types, not just PPP.
> 
> *nod*  This seems like a reasonable consideration.
> 
>> L2TP supports many different pseudowire types, and this patch will only
>> be useful for tunnel switching between PPP pseudowires. Whereas if we
>> implement it within the L2TP core, rather than in the PPP code, we would
>> get switching between all pseudowire types. If we add this patch and
>> then subsequently add switching between other pseudowires in the L2TP
>> core (which we're likely to want to do), then we're left with two
>> different interfaces for doing L2TP tunnel switching in the kernel.
> 
> At least for ethernet pseudowires, it can already be implemented by using 
> an ethernet bridge device.  Besides PPP and ethernet pseudowires, what 
> other types are supported at present by the L2TP core?

Only those two at the moment, but others (ATM etc) can be added if and
when there is demand. To do this at an L2TP level avoids using two
linked PPP interfaces in the case of PPP and two bridged l2tpeth
interfaces in the case of ethernet. I envisage a new L2TP netlink API to
join the datapaths of two L2TP sessions together with no devices being
needed. It would work for all L2TP session types, now and in the future.

>>> The reasoning behind using dev_queue_xmit() rather than outputting directly 
>>> to another PPP channel is to enable the use of the traffic shaping and 
>>> queuing features of the kernel on multihop sessions.

(Continue reading)