L2TP会话建立过程
L2TP会话建立过程中涉及的消息包括：
ICRQ（Incoming-Call-Request）：只有LAC才会发送；每当检测到用户的呼叫请求，LAC就发送ICRQ消息给LNS，请求建立会话连接。ICRQ中携带会话参数。
ICRP（Incoming-Call-Reply）：只有LNS才会发送；收到LAC的ICRQ，LNS就使用ICRP回复，表示允许建立会话连接。
ICCN（Incoming-Call-Connected）：只有LAC才会发送；LAC收到LNS的ICRP，就使用ICCN回复，表示LAC已回复用户的呼叫，通知LNS建立会话连接。
CDN（Call-Disconnect-Notify）：用来通知对端拆除会话连接，并告知对端拆除的原因。
ZLB（Zero-Length Body）：如果本端的队列没有要发送的消息时，发送ZLB给对端。在会话连接和控制连接的拆除过程中，发送ZLB还表示收到StopCCN或CDN。ZLB只有L2TP头，没有负载部分，因此而得名。
会话连接的建立
控制连接成功建立之后，一旦检测到用户呼叫，就请求建立会话连接。与控制连接不同的是，会话连接的建立具有方向性。在NE20E中，会话连接请求是由LAC发起的。会话连接建立过程如图8-7。
L2TP的会话建立由PPP触发。
在设备中，使用命令可以查看本设备上成功建立了哪些会话连接。
会话连接拆除
会话连接拆除的发起端可以是LAC或LNS。发起端通过发送CDN消息报文到对端来通知对端拆除会话连接。对端收到后发送ZLB ACK消息作为回应。图8-8是LAC侧发起会话连接拆除的过程。
L2TP用户端到端上线过程
L2TP的典型组网如图8-9所示：
进行隧道验证的L2TP隧道呼叫建立流程如图8-10。
用户端PC机发起呼叫连接请求；
PC机和LAC端进行PPP LCP协商；
LAC对PC机提供的用户信息进行PAP或CHAP认证；
LAC将认证信息（用户名、密码）发送给RADIUS服务器进行认证；
RADIUS服务器认证该用户，如果认证通过则返回该用户对应的LNS地址等相关信息，并且LAC准备发起Tunnel连接请求；
LAC端向指定LNS发起Tunnel连接请求；
LAC端向指定LNS发送CHAP challenge信息，LNS回送该challenge响应消息CHAP response，并发送LNS侧的CHAP challenge，LAC返回该challenge的响应消息CHAP response；
隧道验证通过；
LAC端将用户CHAP response、response identifier和PPP协商参数传送给LNS；
LNS将接入请求信息发送给RADIUS服务器进行认证；
RADIUS服务器认证该请求信息，如果认证通过则返回响应信息；
若用户在LNS侧配置强制本端CHAP认证，则LNS对用户进行认证，发送CHAP challenge，用户侧回应CHAP response；
LNS再次将接入请求信息发送给RADIUS服务器进行认证；
RADIUS服务器认证该请求信息，如果认证通过则返回响应信息；
验证通过，用户访问企业内部资源。
LNS对用户的认证方式
LNS可对用户进行两次验证：第一次发生在LAC侧，第二次发生在LNS侧。验证模式（Authentication-mode）为“none”也算一种验证。
LNS侧对用户的验证方式有三种：代理验证、强制CHAP验证和LCP重协商。
LCP重协商
如果需要在LNS侧进行比LAC侧更严格的认证，或者LNS侧需要直接从用户获取某些信息（当LNS与LAC是不同厂商的设备时可能发生这种情况），则可以配置LNS与用户间进行LCP重协商。LCP重协商使用相应虚拟接口模板VT上配置的验证方式。此时将忽略NAS侧的代理验证信息。
强制CHAP验证
如果只配置强制CHAP验证，则LNS对用户进行CHAP验证，如果验证不过的话，会话就不能建立成功。
代理验证
如果既不配置LCP重协商，也不配置强制CHAP验证，则LNS对用户进行的是代理验证。
代理验证就是LAC将它从用户得到的所有验证信息及LAC端配置的验证方式传给LNS，LNS会利用这些信息和LAC端传来的验证方式对用户进行验证。
对由NAS发起的VPN服务请求（NAS-Initialized VPN），在PPP会话开始时，用户先和NAS进行PPP协商。若协商通过，则由NAS初始化L2TP通道连接，并将用户信息传递给LNS，由LNS根据收到的代理验证信息，判断用户是否合法。
当LNS使用代理验证时，如果虚拟接口模板VT配置的验证方式为CHAP，而LAC端配置的验证方式为PAP，则由于LNS要求的CHAP验证级别高于LAC能够提供的PAP验证，验证将无法通过，会话也就不能正确建立。
如果在LAC端使用AAA NONE的认证方式，那么无论LAC侧采用PAP验证还是CHAP验证，AAA都不会认证。但送到LNS端以后，LNS端就采用AAA配置的认证方式（如Local、Radius或者NONE）进行认证。
代理验证与VT上的验证方式也有关系：VT上的验证方式不能比LAC侧复杂。如果LAC侧的验证方式为PAP，但LNS的VT上的验证方式为CHAP，则验证不通过。
其他情况下，采用LAC传来的验证方式，不管VT上配的是什么验证方式。
