Layer-2 Tunneling Protocol (L2TP)

Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:

In order to get a better understanding, the lab setup is shown in the picture below.

With PPPoE, a subscriber runs a point-to-point connection (PPP session) to a Broadband Network Gateway (BNG) across that PPPoE connection. In most cases, the PPPoE termination point and PPP session endpoint resides on the same physical device. However, tunneling protocols, such as Layer-2 Tunneling Protocol version 2 (L2TPv2) provide a dynamic mechanism for extending PPP by allowing the PPPoE and PPP endpoints to reside on different devices that are interconnected by an IP network.

There are various networking scenarios where it makes sense to deploy L2TP tunnels, e.g.,

The BNG now acts as a L2TP access concentrator (LAC), which physically terminates the PPPoE session and tunnels the PPP packets across an IP network to the L2TP network server (LNS). The LNS then terminates the logical PPP connection.

In most real-world deployments, L2TP is used with RADIUS authentication. So, in case the PPPoE configuration is already in place as described in module PPPoE Subscribers, the L2TP configuration is pretty simply: just turn on l2tp in the access-profile using the set access access-profile <profile_name> protocol l2tp command. This is the only mandatory command.

However, for a better understanding of L2TP, we first want to configure an L2TP profile in this section. As already mentioned, this step is optional.

The Layer 2 Tunnel Protocol (L2TPv2) pool configuration allows to define local sets of possible L2TP LNS server endpoints using the set access l2tp-pool <l2tp_poolname> syntax. The pool defines LNS IP addresses, the local IP address as well as a shared secret key.

Next, we will define a L2TP profile using the set access l2tp-profile <l2tp_profilename> command. The profile can be used to define various parameters, e.g., the LNS selection algorithm and tunnel and session timers.

Finally, we need to bind the L2TP profile to the existing PPPoE access profile.

So far, we have not used RADIUS in this section, thus we need to create a local user and assign the L2TP pool to it in order to verify our setup.

In order to see some useful CLI output, we need a test subscriber to establish a session with our RBFS device. The virtual lab environment comes with a service node (SN) that has BNG Blaster pre-installed - an open-source test tool that allows to emulate PPPoE subscribers as well as L2TP LNS devices. A short introduction to the BNG Blaster can be found in the Supplementary Material in section BNG Blaster. For more details refer to the BNG Blaster Documentation.

Now let’s open another terminal, log into the service node and start the BNG Blaster:

Once the message ALL SESSIONS ESTABLISHED appears on the screen, you can switch to the RBFS CLI and execute some monitoring commands. The BNG Blaster session is terminated using Ctrl+c. The switch -c 1 instructs the BNG Blaster to establish one session. You can vary the number of session count, however, as we have only one user profile configured, all other sessions will fail to establish. You can also execute the BNG Blaster with the option -I which start the interactive mode.

We can verify that one subscriber session is active. You can use either the show subscriber or the show pppoe session or the show l2tp subscriber command to verify the status of the subscriber sessions.

Note, that the subscriber ID is the same in all outputs and that the status of the PPPoE session is TUNNELED indicating that L2TP is used to tunnel the traffic to an LNS.

Let’s get some more information on the L2TP tunnel. Therefore, we have to extract the tunnel ID (TID) and session ID (SID) that identify the subscriber.

The show l2tp tunnel command provides some useful information about the L2TP tunnels, e.g., status and peer IP address:

The command provides two tunnels, one established and one inactive. The reason for having two tunnels listed is that our L2TP pool contains two LNS definitions. The command clear l2tp tunnel can be used to clean up all inactive tunnels if needed:

In case you have multiple subscribers, you can also view the distribution of sessions among the L2TP tunnels which is also useful to monitor the load:

When L2TP sessions or tunnels are experiencing connectivity issues, it is often useful to see the history of their disconnections. RBFS provides the history knob for the show l2tp tunnel | session command to provide the termination code for further investigation:

The most scalable user management solution is using RADIUS, which allows each subscriber to be assigned individual tunnel and session parameters without defining a large number of L2TP pools and L2TP profiles on the local system. The RADIUS VSAs that are supported by RBFS include Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel-Password, and Tunnel-Preference as described in RFC 2868.

Now, let’s check that RADIUS authentication is working. Therefore, we log into the service node SN once again and restart BNG Blaster with session count of five. As a result, we can verify that all L2TP sessions are established:

We also notice, that the peer names are provided by the RADIUS server as we have only defined LNS1 and LNS2 in our local L2TP pool.

This module outlined the building blocks of Layer Two Tunneling Protocol (L2TPv2). You should be familiar with concepts of L2TP LAC and LNS.

If you have completed the exercise, you can check the results by executing