Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[Subscriber Management] L2TP (LNS) over GRE Tunnels

0

0

Article ID: KB34533 KB Last Updated: 14 Jun 2019Version: 1.0
Summary:

This article describes the L2TP LNS behavior when attempting to terminate L2TP tunnel/sessions over a GRE tunnel.

Symptoms:

MX enabled for enhanced subscriber management will be unable to terminate L2TP sessions originating over a GRE tunnel. 

Topology:

PPPoE-client---ERX-LAC------GRE-TUNNEL-----------MX480-LNS

Using the basic topology note above, the MX480 acting as an LNS will be unable to terminate any L2TP sessions. The L2TP tunnel will establish fine. When the LAC sends a ICRQ (incoming call request) to initiate the session phase, the LNS does respond with a ICRP (incoming call reply).  At this point the LAC will send an ICCN (incoming call connected) which will be seen at the kernel (RE) but the jl2tpd will not.  This will cause the LNS to retransmit the ICRP until the tunnel expires.  
 

Monitoring traffic on the LAC facing GRE interface:

On the MX480, monitoring traffic on the LAC facing GRE interface, it is seen that the ICCN is received to the kernel (RE).

labroot@MX480-R060> monitor traffic interface gr-5/3/0.2 no-resolve   
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on gr-5/3/0.2, capture size 96 bytes

13:36:50.503116  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) |...
13:36:50.517180  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/0)Ns=1,Nr=1 *MSGTYPE(SCCCN)
13:36:50.520893  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/0)Ns=2,Nr=1 *MSGTYPE(ICRQ) *ASSND_SESS_ID(37994) |...
13:36:50.687164  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/19146)Ns=3,Nr=2 *MSGTYPE(ICCN) *TX_CONN_SPEED(1000000000) |...
13:36:51.544618  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/0)Ns=4,Nr=2 ZLB
13:36:51.701215  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/19146)Ns=3,Nr=2 *MSGTYPE(ICCN) *TX_CONN_SPEED(1000000000) |...
13:36:53.644800  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/0)Ns=4,Nr=2 ZLB
13:36:53.801205  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/19146)Ns=3,Nr=2 *MSGTYPE(ICCN) *TX_CONN_SPEED(1000000000) |...
13:36:57.744849  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/0)Ns=4,Nr=2 ZLB
13:36:57.901292  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/19146)Ns=3,Nr=2 *MSGTYPE(ICCN) *TX_CONN_SPEED(1000000000) |...
13:37:00.298147  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[](13084/19146)[hdlc|]
13:37:05.844556  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/0)Ns=4,Nr=2 ZLB
13:37:06.001333  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/19146)Ns=3,Nr=2 *MSGTYPE(ICCN) *TX_CONN_SPEED(1000000000) |...
13:37:10.602478  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[](13084/19146)[hdlc|]
13:37:20.669479  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[](13084/19146)[hdlc|]
13:37:21.944807  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/0)Ns=4,Nr=2 ZLB
13:37:22.101554  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[TLS](13084/19146)Ns=3,Nr=2 *MSGTYPE(ICCN) *TX_CONN_SPEED(1000000000) |...
13:37:30.394079  In IP 35.35.35.35.1701 > 192.164.1.1.1701:  l2tp:[](13084/19146)[hdlc|

 

However, jl2tpd (on the MX480) does not see the ICCN and is showing the retransmits of the ICRP.

Nov  9 13:36:50.509930 allocateLocalTunnelId: got localTunnelId 13084
Nov  9 13:36:50.510084 receive: received L2TP packet type sccrq, from remote address 35.35.35.35, remote port  1701, for local address 192.164.1.1, local port 1701, tunnel Id 0x0, session Id 0x0
Nov  9 13:36:50.510218 send: send L2TP packet type sccrp, for remote  address 35.35.35.35, remote port 1701, from local address 192.164.1.1, local port 1701, L2tpTunnel 0xa, remote tunnel Id 24596, local tunnel Id 13084, remote session Id 0, local session Id 0, Ns 0, Nr 1, re-tries 0
Nov  9 13:36:50.517255 receive: received L2TP packet type scccn, from remote address 35.35.35.35, remote port  1701, for local address 192.164.1.1, local port 1701, tunnel Id 0x13084, session Id 0x0
Nov  9 13:36:50.517558 sendZLB: send L2TP packet type zlb, for remote  address 35.35.35.35, remote port 1701, from local address 192.164.1.1, local port 1701, L2tpTunnel 0xa, tunnel Id 24596, session Id 0, Ns 1, Nr 2
Nov  9 13:36:50.520961 receive: received L2TP packet type icrq, from remote address 35.35.35.35, remote port  1701, for local address 192.164.1.1, local port 1701, tunnel Id 0x13084, session Id 0x0
Nov  9 13:36:50.527771 allocateLocalSessionId: got localSessionId 19146
Nov  9 13:36:50.528132 send: send L2TP packet type icrp, for remote  address 35.35.35.35, remote port 1701, from local address 192.164.1.1, local port 1701, L2tpTunnel 0xa, remote tunnel Id 24596, local tunnel Id 13084, remote session Id 37994, local session Id 19146, Ns 1, Nr 3, re-tries 0
Nov  9 13:36:51.542825 send: send L2TP packet type icrp, for remote  address 35.35.35.35, remote port 1701, from local address 192.164.1.1, local port 1701, L2tpTunnel 0xa, remote tunnel Id 24596, local tunnel Id 13084, remote session Id 37994, local session Id 19146, Ns 1, Nr 3, re-tries 0
Nov  9 13:36:53.642831 send: send L2TP packet type icrp, for remote  address 35.35.35.35, remote port 1701, from local address 192.164.1.1, local port 1701, L2tpTunnel 0xa, remote tunnel Id 24596, local tunnel Id 13084, remote session Id 37994, local session Id 19146, Ns 1, Nr 3, re-tries 1
Nov  9 13:36:57.742834 send: send L2TP packet type icrp, for remote  address 35.35.35.35, remote port 1701, from local address 192.164.1.1, local port 1701, L2tpTunnel 0xa, remote tunnel Id 24596, local tunnel Id 13084, remote session Id 37994, local session Id 19146, Ns 1, Nr 3, re-tries 2
Nov  9 13:37:05.842853 send: send L2TP packet type icrp, for remote  address 35.35.35.35, remote port 1701, from local address 192.164.1.1, local port 1701, L2tpTunnel 0xa, remote tunnel Id 24596, local tunnel Id 13084, remote session Id 37994, local session Id 19146, Ns 1, Nr 3, re-tries 3
Nov  9 13:37:21.942827 send: send L2TP packet type icrp, for remote  address 35.35.35.35, remote port 1701, from local address 192.164.1.1, local port 1701, L2tpTunnel 0xa, remote tunnel Id 24596, local tunnel Id 13084, remote session Id 37994, local session Id 19146, Ns 1, Nr 3, re-tries 4
Nov  9 13:37:38.042811 send: send L2TP packet type icrp, for remote  address 35.35.35.35, remote port 1701, from local address 192.164.1.1, local port 1701, L2tpTunnel 0xa, remote tunnel Id 24596, local tunnel Id 13084, remote session Id 37994, local session Id 19146, Ns 1, Nr 3, re-tries 5
Cause:

In this set up, the GRE header is encapsulated at the LAC and removed at the LNS. The GRE tunnel is between the LAC and the LNS only. During the GRE driver packet processing, the GRE header is removed and the underlying L2TP packet is sent to the jL2tpd daemon in the legacy RTSOCK path. These packets reach directly to jL2tpd by-passing bbe-smgd. However, it is expected to receive Tunnel Control Packets (SCCRQ , SCCCN) and the first session control packet (ICRQ) at jL2tpd which is happening correctly.  But after the installation of /120 bit Tunnel Control Route, the ICCN packet is not being sent from the RE kernel to jL2tpd.

This is because after the /120 bit route installation, the GRE Driver at the kernel performs a route lookup on the underlying L2TP packet. Since the route lookup at the kernel points to Pseudo-Ifl Next-hop, packets are dropped at the kernel itself. If no route is found, the packet is injected back to Raw IP Processing, thus reaching the jL2tpd daemon. (Raw_IP -> IP - > UDP -> jL2tpd ).

In enhanced subscriber management, the correct packet path for the L2TP session packet is that PFE adds PACKET_TAG_VBF to L2TP control packet and it is being sent from the kernel raw socket driver to bbe-smgd.

Solution:

Enhanced Subscriber Management does not support L2TP over GRE tunnels. 

Work-around:

Use a hair-pin topology to terminate the GRE and route L2TP back to the same MX. In other words, physically loop a cable back-to-back on the same system to route traffic from the GRE to the LNS or terminate the GRE tunnel to a different router and route traffic to the LNS.
 
 

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search