Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Feb 2000 15:07:28 -0500 (EST)
From:      David Gilbert <dgilbert@velocet.ca>
To:        freebsd-net@freebsd.org
Subject:   L2tp thoughts an implementations.
Message-ID:  <14497.51456.635308.156936@trooper.velocet.net>

next in thread | raw e-mail | index | archive | help

--5Wcwg9B2VV
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

Probably about the third mailing list that I have send the message
below to, but Archie recomended that I forwarde it on here.

Anyways... I also recently said:

Archie> Yes, that sounds like a good idea (though I don't know much
Archie> about VLAN).

VLan is an exceedingly simple protocol.  As I understand it, you add a 
4 byte "number" to a raw ethernet packet.  The 4 byte number is the
vlan number.  Having finished some of the packet munging stuff for
l2tp, I'd have to say that this is so exceedingly simple, it might be
worth just putting inside the ethernet node itself... maybe.  I
suppose it could go either way.

Now... I started vaguely wondering to myself if we could create a
ng_route node... which would have a routing table similar to the
kernel's.  This would give you CISCO-like vlan power --- you'd create
a "vrouter" by attaching certain vlans to a route node.

(which is also a relavant, but separate topic for this list --- it
would seem that netgraph tech would make a more "appropriate" or
"correct" vlan config ... considering the possibilities)


--5Wcwg9B2VV
Content-Type: message/rfc822
Content-Description: forwarded message
Content-Transfer-Encoding: 7bit

MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <14497.40372.136664.641305@trooper.velocet.net>
X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs  Lucid
From: David Gilbert <dgilbert@velocet.ca>
Subject: Netgraph and l2tp
Date: Wed, 9 Feb 2000 12:02:44 -0500 (EST)

Netgraph is seriously cool technology.  I think we've briefly touched
on this before, but I've been spending most of my week creating an
l2tp node for it, so I thought I'd comment more on it's structure and
use.  For further reading, see your local FreeBSD (or NetBSD, but I
believe Theo has rejected it) machine or

http://www.FreeBSD.org/cgi/man.cgi?query=netgraph&apropos=0&sektion=0&manpath=FreeBSD+3.4-RELEASE&format=html

Anyways, l2tp is somewhat like pptp in that encapsulates ppp over
UDP.  It is unlike pptp in that it encapsulates many PPP connections
over one UDP tunnel.  From RFC-2661:

                          +-----+                               +-----+
                          |     |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~|     |
                          | LAC |                               | LNS |
                          |     #######Control Connection########     |
 [Remote]                 |     |                               |     |
 [System]------Call----------*============L2TP Session=============*  |
   PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  |
                          |     |                               |     |
 [Remote]                 |     |                               |     |
 [System]------Call----------*============L2TP Session=============*  |
   PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  |
                          |     |                               |     |
                          |     |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|     |
                          +-----+                               +-----+


... and I'm implementing the "LNS" (for now).  Basically, in the ADSL
case, remote system to LAC is PPPoE and the LAC then forwards the PPP
frames inside the L2TP tunnel.

What this means at my end that I have to manage the L2TP "glue," but
the majority of the processing concerns stripping off the L2TP header
(or adding it) with the remainder of the processing being straight
PPP.

Now, netgraph already has the following general PPP setup:

ksocket <--> ppp <--> bpf <--> iface
(UDP)         ^                (ng0)
              |
              v
           socket <--> mpd (userland)

mpd manages the whole lot, communicating through the ng_socket node.
MPD does authentication and other administration, but the ng_ppp node
does all the regular PPP stuff.  Encryption and/or compression are
provided by hooks on the ng_ppp node (hooks and nodes for this arn't
shown).  The ng_bpf node is simply present to detect packets to bring
up the link on certain kinds of traffic.

Now... to do L2TP, we're modifying this picture somewhat.  In the
following <-=> means "one to many."

ksocket <--> l2tp <-=> ppp <--> iface
               ^      //
               |     //
               v    /
              socket <--> mpd

In this case, mpd manages one (or more) l2tp nodes which each manage
many (potentially thousands) of ppp nodes.  I'm axeing the bpf node
since the remote end will always initiate the connection.

The cool part of this is that everything but the l2tp "glue" is
already written.  I've had to learn a few things about mbufs to work
on ng_l2tp, but I'm getting around it.

I've been thinking lately of working on adding vlan hooks to ethernet
interfaces when I'm done this ... there already is vlan stuff in
FreeBSD, but it would appear more elegant to use the netgraph stuff
(and painfully simple) to do vlans.

Using netgraph would also allow me to (basically) create vrouter type
capability in FreeBSD.  (In doing this, you might connect the vlan10
hook of fxp0 to the vlan35 hook of fxp1 --- effectively bridging the
vlan.  With a few more netgraph nodes, you could mix in things like
bpf and/or some forms of firewalling or routing netgraph nodes.)

Anyways... enough cool toys for now.

Dave.

-- 
============================================================================
|David Gilbert, Velocet Communications.       | Two things can only be     |
|Mail:       dgilbert@velocet.net             |  equal if and only if they |
|http://www.velocet.net/~dgilbert             |   are precisely opposite.  |
=========================================================GLO================

--5Wcwg9B2VV--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14497.51456.635308.156936>