l2tpns issueshttps://code.ffdn.org/l2tpns/l2tpns/-/issues2022-12-26T23:58:30Zhttps://code.ffdn.org/l2tpns/l2tpns/-/issues/15alignment support2022-12-26T23:58:30Zsthibaulalignment supportAs reported on https://bugs.debian.org/341657 , l2tpns has troubles on architectures with alignment constraints. A patch was provided, even if probably a bit outdated.As reported on https://bugs.debian.org/341657 , l2tpns has troubles on architectures with alignment constraints. A patch was provided, even if probably a bit outdated.https://code.ffdn.org/l2tpns/l2tpns/-/issues/14Add XDP offloading2022-08-12T20:56:35ZzorunAdd XDP offloadingPreliminary notes on XDP offloading
==============
XDP is a eBPF-based mechanism to run custom packet processing code in
the kernel, directly in the device driver for maximum performance.
l2tpns could offload packet processing tasks to...Preliminary notes on XDP offloading
==============
XDP is a eBPF-based mechanism to run custom packet processing code in
the kernel, directly in the device driver for maximum performance.
l2tpns could offload packet processing tasks to XDP, including L2TP
encapsulation/desencapsulation. Control packets and corner cases would
still be handled by the l2tpns process.
Tradeoffs of using XDP
----------------------
It is important to understand that l2tpns will never "see" the offloaded
packets. As such, several features implemented in l2tpns will become inoperative,
such as:
- session throttling
- packet interception
- access lists
XDP offload design overview
---------------------------
The XDP offload design is made of several parts:
- a "Internet-side" or "encapsulating" XDP program handling downstream
traffic (packets whose destination is a subscriber). It will typically
be attached to one or more "Internet-facing" network interfaces. This
program will match relevant packets based on their destination IP
address, encapsulate them in a PPP/L2TP frame, and forward them directly
to the right L2TP tunnel endpoint.
- a "subscriber-side" or "decapsulating" XDP program handling upstream
traffic (packets coming from subscribers). It needs to be attached to
the network interface facing subscribers. This program will intercept
L2TP packets, verify they belong to a valid session, decapsulate them,
and then forward the resulting IP packets directly to their destination.
It will not intercept control packets (e.g. IPCP, DHCPv6) so that they
can be handled by l2tpns in the usual way.
- a set of eBPF maps storing the current state of tunnels and session. It
is updated from userspace by l2tpns, and accessed by the XDP programs.
More precisely, the "encapsulating" XDP program needs this data to know
for which session and to which tunnel endpoint it needs to forward
encapsulated packets; while the "decapsulating" XDP program needs this
data to check for non-existing sessions or spoofed IP addresses from
subscribers before it accepts to decapsulate and forward packets.
- a eBPF map storing traffic statistics for each session. It is updated
by the XDP programs for each packet they handle, and accessed regularly
by l2tpns. There is actually one map for each CPU to avoid concurrent
updates.
- a loader that runs on l2tpns startup and attaches the XDP programs on
the relevant network interfaceshttps://code.ffdn.org/l2tpns/l2tpns/-/issues/13leverage the kernel l2tp_ppp driver2024-01-14T21:54:02Zsthibaulleverage the kernel l2tp_ppp driverHello,
While discussion was going on on #fdn about l2tpns being essentially slow because of kernel/user ping-pong, I was looking at what actually exists in the kernel, and there actually is a l2tp_ppp driver that would allow the data pa...Hello,
While discussion was going on on #fdn about l2tpns being essentially slow because of kernel/user ping-pong, I was looking at what actually exists in the kernel, and there actually is a l2tp_ppp driver that would allow the data path to stay within the kernel.
Samuelhttps://code.ffdn.org/l2tpns/l2tpns/-/issues/10Verbose warning about IPV6CP2023-04-23T11:57:05ZsthibaulVerbose warning about IPV6CPHello,
At FDN our logs get spammed with
```
No interface identifier in IPV6CP request
```
over and over for the same sessions, every 3 seconds.
Perhaps l2tpns should be returning an explicit nak rather than leaving the peer without a...Hello,
At FDN our logs get spammed with
```
No interface identifier in IPV6CP request
```
over and over for the same sessions, every 3 seconds.
Perhaps l2tpns should be returning an explicit nak rather than leaving the peer without an answer?
Samuelhttps://code.ffdn.org/l2tpns/l2tpns/-/issues/7Cluster mode should not be enabled by default2021-01-15T16:52:33ZzorunCluster mode should not be enabled by defaultCurrently, the cluster mode is enabled by default (l2tpns.c):
```
if (!config->cluster_address) config->cluster_address = inet_addr(DEFAULT_MCAST_ADDR); ...Currently, the cluster mode is enabled by default (l2tpns.c):
```
if (!config->cluster_address) config->cluster_address = inet_addr(DEFAULT_MCAST_ADDR);
if (!config->cluster_port) config->cluster_port = CLUSTERPORT;
if (!*config->cluster_interface)
strncpy(config->cluster_interface, DEFAULT_MCAST_INTERFACE, sizeof(config->cluster_interface) - 1);
```
This is confusing because `DEFAULT_MCAST_INTERFACE` is `eth0`, which causes l2tpns to fail to start if eth0 does not exist, even if nothing in the configuration enables clustering.
l2tpns should only enable cluster mode if `cluster_interface` is explicitly given in the configuration.https://code.ffdn.org/l2tpns/l2tpns/-/issues/6Clarify bandwidth usage displayed in the cli ("uptime" command)2020-11-08T19:20:02ZzorunClarify bandwidth usage displayed in the cli ("uptime" command)It is possible to obtain the current bandwidth from the CLI:
```
host> uptime
Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569
```
The format is explained in the HTML manual, but it's really not self-explanatory.
So...It is possible to obtain the current bandwidth from the CLI:
```
host> uptime
Bandwidth: UDP-ETH:6/6 ETH-UDP:13/13 TOTAL:37.6 IN:3033 OUT:2569
```
The format is explained in the HTML manual, but it's really not self-explanatory.
Something like the following would be easier to understand:
```
Downstream bandwidth | 13 Mbps | 3.0 Kpps
Upstream bandwidth | 6 Mbps | 2.6 Kpps
Total bandwidth | 19 Mbps | 5.6 Kpps
```https://code.ffdn.org/l2tpns/l2tpns/-/issues/5Stop using kernel proto 42 because it's also used by babeld2021-01-31T16:14:39ZzorunStop using kernel proto 42 because it's also used by babeld`l2tpns` inserts route into the kernel with `proto 42`, which is a well-chosen arbitrary value.
Unfortunately, the author of `babeld` had the same idea. And he has friends in high places so that this (unofficial) assignment [is in iprou...`l2tpns` inserts route into the kernel with `proto 42`, which is a well-chosen arbitrary value.
Unfortunately, the author of `babeld` had the same idea. And he has friends in high places so that this (unofficial) assignment [is in iproute2](https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=1fa804e0d37084871a84480d379272a82d025d25). This shows up when displaying routes added by `l2tpns` on a recent Debian:
```
$ ip r show dev tun0
XX.XX.XX.XX proto babel scope link
```
It's only cosmetic, but I think we should change our value to avoid confusion (and also declare the new value in iproute2 to avoid future conflicts)
The problem is that it's a breaking change: external tools such as Bird may match on the proto number to identify routes added by `l2tpns`. Either we keep the current situation, or we introduce this change in a major release (like 3.0).https://code.ffdn.org/l2tpns/l2tpns/-/issues/2l2tpns should give an error when using incorrect configuration2021-10-15T20:11:25Zzorunl2tpns should give an error when using incorrect configurationI spent a lot of time debugging an issue that turned out to be a typo in the configuration file:
```
set cluster_inferface ens13
```
instead of `cluster_interface`.
l2tpns should definitely give an error when it does not understand a c...I spent a lot of time debugging an issue that turned out to be a typo in the configuration file:
```
set cluster_inferface ens13
```
instead of `cluster_interface`.
l2tpns should definitely give an error when it does not understand a configuration line.