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."
next prev parent 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).