ProL2TP 1.6 is now available!

Mon 03 June 2013
By Tom Parkin

The next major release of ProL2TP, version 1.6, went live over the weekend. Our existing customers will be able to download the latest revision from the FTP servers, and anyone can request a free trial using the links from the ProL2TP main website.

While there aren't a lot of shiny new bells and whistles in this release, I'm still excited about it. We've built on the solid foundations of the 1.5 release to add another level of quality and robustness, making ProL2TP 1.6 easier to use, more efficient, and more scalable than ever before.

Let's take a look at the key improvements in this release.

Scalability and runtime performance

The ProL2TP 1.5 release made some fantastic performance improvements by reworking internal libraries to make the core of prol2tpd more efficient. The 1.6 release takes this a step further, rolling some of the same techniques out into the rest of the prol2tpd codebase. Every significant lookup that prol2tpd carries out is now more scalable, and the effects of this on runtime performance can be seen everywhere from initial configuration file parsing on startup (over twenty times faster) to tunnel bringup (over twice as fast). This is another significant step forwards for embedded and large-scale customers alike.

In addition to the performance improvements in prol2tpd, this release also reworks the "funnelbridge" concept we've previously used in session scripts. Users wanting to bridge large numbers of L2TPv3 Ethernet pseudowires can use the funnelbridge plugin and admin app to handle automatic creation of bridges, veth links, and ebtables entries. The funnelbridge plugin easily scales to accomodate tens of thousands of sessions.

Finally, for users needing very large session populations, prol2tpd is now able to automatically autogenerate L2TP interface names (see the autoname_interfaces configuration option for details). This works around a limitation in the Linux kernel which would otherwise restrict the system to around thiry-two thousand network interfaces. If you need to create more sessions than this, autoname_interfaces allows you to do so.

System visibility

ProL2TP has always provided a flexible and comprehensive logging system, which allows the user to monitor every facet of prol2tpd's behaviour. The 1.6 release tweaks this system a little to provide more a more intuitive interface for debugging typical integration and deployment issues.

Firstly, prol2tpd now supports logging directly to a file. While this has always been possible by fiddling with syslog settings, it is now directly and easily configurable via the prol2pd.conf log_file option.

Alongside the main log output, 1.6 adds a new logging facility: the log buffer. This is a low overhead in-memory log, which can be used to capture verbose information about a particular problem session or tunnel without impacting on the runtime performance of prol2tpd or the system as a whole. The memory log buffer can be configured separately to the main log, and is queried using the prol2tp monitoring application. Read up on the log_buffer configuration option for more information.

System visibility is also improved by the addition of per-tunnel and per-session event logs, which provide a bare-bones history of the event transitions for each tunnel and session. Being able to directly inspect the event history allows an operator to quickly determine what has lead up to the current system state without needing to pick through a large log file or break out traffic analysis tools. The event logs can be queried using the prol2tp monitoring application in a similar way to the log buffer.

Interoperability

ProL2TP hasn't historically supported LNS-initiated calls, which has created some interoperability issues for some customers. For the 1.6 release, prol2tpd now fully supports this feature, including tiebreaker and collision detection support for L2TPv3 session setup.

For this release, prol2tpd also ships with a new interoperability plugin which helps work around some inconsistencies we've found when trying to communicate with other L2TP network equipment. Some of these things arise from areas of ambiguity in the L2TP RFCs, while others are due to vendors relying on vendor-specific AVPs where a standard one should be used. The new plugin allows prol2tpd to work with these pieces of equipment.

Robustness

The 1.6 release includes a number of bug fixes in prol2tpd itself. In addition, our backport l2tp-drivers dkms package includes a significant number of fixes and improvements from the upstream Linux kernel. Our policy is to push kernel changes upstream as soon as they're available, but our backport package includes those updates for customers running older kernels. At the time of writing, the backport package includes the latest and greatest Linux L2TP driver support for kernel versions 2.6.37 onwards.

For users wishing to lock down their ProL2TP deployments, the prol2tpd control and monitoring applications now add an extra layer of control to prevent unauthorised access. Admins may add read-write or read-only access permissions to individual user accounts by setting group memberships for the new prol2tp and prol2tpadmin user groups. The root account still retains full access.

Finally, ProL2TP 1.6 includes some new self-preservation features which allow an operator to limit the execution of event scripts and pppd instances in order to protect prol2tpd against malicious clients or unexpected load conditions. There are three new configuration parameters which limit child process execution:

  • event_script_rate_limit limits the rate at which new event scripts can be spawned. The limit is the number of new scripts in a 1-second time window.
  • event_script_concurrency_limit limits the total number of event scripts which may be running at any one time, irrespective of the startup rate.
  • ppp_startup_rate_limit limits the rate at which pppd instances may be spawned. The limit is the number of new pppd instances in a 1-second time window.

These new rate-limiting parameters, while not a replacement for firewalls or other network security infrastructure, provide another tool for users to more efficiently protect their ProL2TP servers against overload.

Conclusion

As I mentioned earlier, ProL2TP 1.6 doesn't add a lot of bells and whistles, but that doesn't make it any less compelling. What we've tried to do with this release is to make ProL2TP easier to work with, more scalable, and more interoperable, and I believe we've made great progress on all fronts. If you need L2TPv2/v3 support on a Linux platform, whether an OEM embedded client box, or an big server running as part of an ISP network, why not ask us for a free trial today?