netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin LaHaise <bcrl@kvack.org>
To: Mitar <mmitar@gmail.com>
Cc: netdev@vger.kernel.org, Nejc Skoberne <nejc@skoberne.net>,
	Jernej Kos <kostko@unimatrix-one.org>,
	gw.2012@tnode.com
Subject: Re: Ethernet-over-UDP virtual network interface
Date: Thu, 8 Mar 2012 11:11:38 -0500	[thread overview]
Message-ID: <20120308161138.GB23774@kvack.org> (raw)
In-Reply-To: <CAKLmikOVydmSJEBWwDc=Jv4XPMi3dsS+Pn9=BP_bBePD0L7K8A@mail.gmail.com>

On Tue, Mar 06, 2012 at 12:58:44AM +0100, Mitar wrote:
> I would like something state-less. I see L2TPv3 has support for

How stateless?

> unmanaged tunnels, but they still require tunnel id and session id
> what (if I assume that they have to be unique) makes it useless for
> our case. We have (if I simplify) a star-shaped topology with a
> central server in the middle. To the central server WiFi nodes
> (hundreds of them) connect. But we do not really want to require from
> a central server to know each WiFi node and prepare its tunnel
> endpoint for each node. We would just like that there would be virtual
> interface and UDP port and any packet send to the UDP port would be
> decapsulated and output through that virtual interface. The only thing
> which we would have to make sure is that each WiFi node has a virtual
> interface with unique MAC address.

L2TP is commonly used for star topology deployments, but with more 
flexibility.  The typical scenario is to use LACs (L2TP Access 
Concentrators) on the edge of the network to tunnel incoming sessions 
from clients to LNSes (L2TP Network servers) that actually perform the 
routing for the network.  There is some state involved, but tunnels can 
be configured without a password, effectively making the addition of new
LACs requiring no manually configured state on the LNS.  The Babylon PPP 
stack that I added L2TP and PPPoE support for is able to perform tunnel 
switching on incoming PPPoE or L2TP sessions.  Sessions can be directed to 
different LNSes based on the username an incoming session authenticates 
as.  It only supports L2TPv2 at present, though, but adding L2TPv3 wouldn't 
be too hard.

		-ben
-- 
"Thought is the essence of where you are now."

  reply	other threads:[~2012-03-08 16:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-04 11:30 Ethernet-over-UDP virtual network interface Mitar
2012-03-04 12:21 ` Denys Fedoryshchenko
2012-03-04 13:58   ` Mitar
2012-03-04 16:24 ` Emanuil Hristov
2012-03-04 17:01 ` Benjamin LaHaise
2012-03-05 23:58   ` Mitar
2012-03-08 16:11     ` Benjamin LaHaise [this message]
2012-03-10 16:31       ` Mitar
2012-03-10 17:06         ` Benjamin LaHaise
2012-03-11  3:08           ` Mitar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120308161138.GB23774@kvack.org \
    --to=bcrl@kvack.org \
    --cc=gw.2012@tnode.com \
    --cc=kostko@unimatrix-one.org \
    --cc=mmitar@gmail.com \
    --cc=nejc@skoberne.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).