当前位置：首页 > news >正文

L2TPv2-原理浅谈+报文示例+简易配置-RFC2661

news 2025/10/8 10:58:08

个人认为，理解报文就理解了协议。通过报文中的字段可以理解协议在交互过程中相关传递的信息，更加便于理解协议。

因此本文将在 L2TP 协议报文的基础上进行介绍。

自动换行
L2TP：
在这里插入图片描述

关于 L2TPv2 协议基本原理，可参考RFC2661-Layer Two Tunneling Protocol “L2TP”。
关于 L2TPv3 协议基本原理，可参考RFC3931-Layer Two Tunneling Protocol - Version 3。
关于 L2TP 协议承载组播流的基本原理，可参考RFC4045-Extensions to Support Efficient Carrying of Multicast Traffic in L2TP。
关于 L2TP 故障切换基本原理，可参考RFC4951-Fail Over Extensions for L2TP “failover”。
关于 L2TP 带宽协商的基本原理，可参考RFC5515-L2TP Access Line Information AVP Extensions。

其他相关资料可参考：

关于L2TP承载HDLC帧的相关原理，可参考RFC4349-HDLC Frames over L2TPv3。
关于L2TP承载ATM帧的相关原理，可参考RFC4454-ATM over L2TPv3。
关于L2TP承载Frame Relay的相关原理，可参考RFC4591-Frame Relay over L2TPv3。
关于L2TP承载Ethernet帧的相关原理，可参考RFC4719-Transport of Ethernet Frames over L2TPv3。
关于Circuit Status AVP的精细错误状态码，可参考RFC5641-L2TPv3 Extended Circuit Status Values。
关于L2TP协议的具体使用，可查看Cisco-Set Up L2TP Tunnel Between a Windows Machine and a Cisco Router。
关于L2TP协议相关参数的定义，可查看IANA发布的Layer Two Tunneling Protocol “L2TP”。
关于IPvX协议所使用的协议号，可查看IANA发布的Assigned Internet Protocol Numbers。
关于常用TCP/UDP知名端口的定义，可参考IANA发布的Service Name and Transport Protocol Port Number Registry。

…

L2TP还存在其他相关RFC，感兴趣者可查阅相关资料。

L2TP 有多种应用场景，此处仅介绍其中常用的 LAC/LNS pair 用法。个人能力有限，有问题可私信交流。

目录
1.背景介绍
- 1.1.L2TP简介
- 1.2.相关术语
2.L2TP基本原理
- 2.1.L2TP的报文格式
- 2.2.L2TP控制消息的AVP
- - 2.2.1.Message Type AVP和Result Code AVP
  - 2.2.2.Control Connection Management类AVP
  - 2.2.3.Call Management类AVP
  - 2.2.4.Link Status类AVP
  - 2.2.5.ICCN消息中的代理认证AVP
- 2.3.L2TP协议的生命周期
- - 2.3.1.Control Connection和Session的建立
  - 2.3.2.隧道数据的转发和维护
  - 2.3.3.Control Connection和Session的拆除
3.L2TPv2实例
- 3.1.L2TPv2基本实例
- 3.2.L2TPv2协议交互及状态查看
更新

1.背景介绍

1.1.L2TP简介

在《博客-PPP协议原理介绍+报文分析+配置指导-RFC1661》中我们介绍了可以传递多种协议的 L2 PPP 协议。通常，用户可以通过宽带拨号等 PPP/PPPoE 方式连接到 NAS(Network Access Server)，由 NAS 分配地址获取上网权限。此时 PPP session 和 2 层网络都终结于 NAS 设备上。

L2TP 协议扩展了 PPP 模型，允许 PPP session 和 2 层网络终结于不同设备上。此时，2 层网络可以终结于本地，而 PPP 作为 L2TP 的 paylaod 可以将 session 终结于远端设备上。

VPDN(Virtual private dial-up networks，虚拟私有拨号网络) 是一类在公网上提供拨号访问服务的协议统称，目前可找到最早的资料来源于 Cisco 发布的《VPDN Technology Overview》。VPDN 技术主要包括 L2F、PPTP 和 L2TP 三种协议。通过使用 2 层隧道在客户端和私网之间创建虚拟 PPP 连接访问。目前主要用于为企业、小型 ISP、移动办公人员等提供终端跨公网接入企业内网服务。
其他 VPDN 协议可参考《RFC2341-Cisco Layer Two Forwarding (Protocol) “L2F”》，以及《RFC2637-Point-to-Point Tunneling Protocol》。

L2TP 协议首先可以利用其承载的 PPP 协议提供的 CHAP/PAP 来提供认证的安全性，其次 L2TP 协议定义的 LAC 和 LNS 角色可以将用户信息通告给 RADIUS 等 AAA 服务器来提供用户的接入及计费控制。并且认证计费可 LAC 和 LNS 任意一个角色上完成。

1.2.相关术语

为了进一步描述 L2TP 相关原理，此处首先介绍下《RFC2661-Layer Two Tunneling Protocol “L2TP”》和《RFC3931-Layer Two Tunneling Protocol - Version 3》中定义的相关术语。

Client/Remote System：通过电路连接到 LAC 的终端系统或路由器。这里同一称用户。
Circuit：电路。一种物理或逻辑上广泛的 2 层连接。
PW：Pseudowire，伪线。传递数据包的模拟电路。
PW Type：Pseudowire Type，伪线类型。传递数据包的方式或承载数据的协议，例如 PPP、Ethernet、Frame Relay 等。

LCCE：L2TP Control Connection Endpoint，L2TP 控制连接点。也即 L2TP 隧道的端点，可以分为 LAC 和 LNS。
LAC：L2TP Access Concentrator，L2TP 接入集中器。接收来自用户的信息并将其传递给 L2TP 隧道另一端的 LNS。LAC 是网络中的物理 2 层终结者。
LNS：L2TP Network Server，L2TP 网络服务器。LNS 是 LAC 从用户通过 L2TP 隧道传输的 PPP 会话逻辑终止点，用于处理封装于网络层的数据帧。LNS 是网络中的逻辑 2 层终结者。

LAC 和 LNS 仅针对于特定的用户或 session。一台物理设备可能同时作为某些 L2TP session 的 LAC 和某些 L2TP session 的 LNS 角色存在。
peer 专指 LAC 和 LNS 之间的关系，也即两者互为 peer。

Call：呼叫。一次用户与 LAC 之间的连接。L2TP 用于标识电路处于 up 还是 active 状态，可分为 Incoming Call 或 Outgoing Call。

Incoming Call：LAC 收到的用户呼叫，并需要将信息发送给 LNS。可以由特定流量触发，例如 PPPoE 消息。
Outgoing Call：由 LNS 主动发起向 LAC 通告的呼叫。
Called Number：被叫号码。向呼叫接收者指示拨打者用来联系的数字标识。
Calling Number：主叫号码。向呼叫接收者指示拨打者的数字标识。

ZLB Message：Zero-Length Body (ZLB) Message，0 长内容消息。仅包含 L2TP 头，用于对 L2TP Control Message 的可靠性确认。可以类似于 TCP 的 ACK-flag 作用。

ZLB Message 示例。

AVP：Attribute Value Pair，属性值对。L2TP Control Message 中携带的一个或多个独特属性及其由该属性识别的实际值的值的可变长度字段。主要用于建立、维护和关闭 L2TP 的控制连接。
可以类比为其他协议的 TLV。

点击此处回到目录

2.L2TP基本原理

2.1.L2TP的报文格式

L2TP 消息可以分为 control messages 控制消息和 data messages 数据消息。控制消息用于建立、维护和清除 tunnel 和 call。数据消息用于在 tunnel 上封装 PPP 帧。通过可靠的控制通道，控制消息可以保证信息交互的完整性。而数据消息不具备丢包的重传功能。
在这里插入图片描述并且控制消息和数据消息可以承载于不同网络类型中。

具体来说，L2TP 消息可以由 IP(Protocol ID = 115 )、UDP(Port Number 1701)、Frame Relay、Asynchronous Transfer Mode 和 MPLS 来承载。
自动换行
《RFC2661-Layer Two Tunneling Protocol "L2TP"的8.1.L2TP over UDP/IP章节》中介绍当 L2TP 消息由 UDP 来承载时：
1@：L2TP 选择一个可用的端口作为源 UDP 端口，目的端口使用已注册的 1701。一旦源和目标端口及地址确定后，它们在隧道的整个生命周期中必须保持不变。
2@：任何 L2TP 实现的默认设置是必须为控制消息和数据消息启用 UDP 校验和。L2TP 实现可以提供一个选项以禁用数据消息的 UDP 校验和。
3@：运行在不支持 L2F 系统上的 L2TP 实现必须静默丢弃所有 L2F 数据包。
4@：L2TP/UDP/IP 传输是不可靠的传输。如果既未启用 PPP 可靠传输，也未通过 AVP type 39 = Sequencing Required 启用 L2TP 数据消息序列号，则在某些情况下不应使用 PPP 的 TCP 头压缩功能。

L2TP 隧道的建立必要包含 2 部分：

由控制消息建立控制连接。
由 Incoming Call/Outgoing Call 触发建立 session，并由数据消息具体承载进行信息交互。

自动换行
L2TP Header Format：
在这里插入图片描述 T-bit：Type-bit，L2TP 消息类型。置位 1 时表示控制消息，置位 0 时表示数据消息。
L-bit：Length-bit，长度标识。置位 1 时表示 L2TP Header 存在可选的 Length 字段。L2TP 控制消息必须置位 L-bit。
S-bit：Sequence-bit，序列号标识。置位 1 时表示 L2TP Header 存在可选的 Ns 和 Nr 字段。L2TP 控制消息必须置位 S-bit。
O-bit：Offset-bit，偏移标识。置位 1 时表示 L2TP Header 存在可选的 Offset Size 字段。L2TP 控制消息必须不置位 S-bit。
P-bit：Priority-bit，优先级标识。置位 1 时表示该数据消息应该优先处理。L2TP 控制消息必须不置位 P-bit。一种使用方式是，可以用于指示对 L2TP 承载的 LCP echo requests 的优先响应。

Ver：4bits，version 标识。L2TP 协议固定取 2。

《RFC2341-Cisco Layer Two Forwarding (Protocol) “L2F”》中定义的 L2F 协议与 L2TP 具有部分相同的封装格式，当 Ver 字段取 1 时表示承载的协议为 L2F 协议。
而在《RFC3931-Layer Two Tunneling Protocol - Version 3》中新定义的 L2TP Header 也具有部分相同的封装格式，当 Ver 字段取 3 时表示承载的协议为 L2TPv3 协议。

Length (opt)：16bits，可选的长度字段。在控制消息中必须出现，在数据消息中有选择的出现。用于标识整个 L2TP 控制消息的长度，单位字节。
Tunnel ID：16bits，用于标识控制连接。仅具有本地意义的标识符。

Tunnel ID 在 L2TP 控制消息建立控制连接时由对端指定。LCCE 节点会携带 AVP type 9 = Assigned Tunnel ID AVP 用于为 peer 指定向自己发送消息时携带的 Tunnel ID。此后，peer 进行信息交互时携带对方为自己指定的 Tunnel ID。

Session ID：16bits，用于标识隧道内的 session。仅具有本地意义的标识符。

Session ID 在 L2TP 控制消息建立控制连接时通过携带 AVP type 14 = Assigned Session ID AVP 来通告。

Ns (opt)：16bits，message sequence number。数据消息或控制消息的序列号。
Nr (opt)：16bits，last received message number。期望收到下一个控制消息的序列号。

《RFC2661-Layer Two Tunneling Protocol "L2TP"的5.8.Reliable Delivery of Control Messages章节》中介绍这是一种低级别的可靠传输服务。这是一种滑动窗格机制可以提供拥塞重传保护。
1@：发送 L2TP 消息时，Ns 从 0 开始。每条后续消息都使用 Ns + 1 发送。
2@：Ns 的 16bits 可表示 0-65535(2¹⁶ - 1) 内的范围值，并且该值应当是循环使用的。也即当某一个消息 Ns = 65535 时，下一个 L2TP 控制消息的 Ns 为 0。在此种情况下定义了重复 Ns 包的概念。当收到 L2TP 控制消息的 Ns 值在其之前的 32767(2¹⁵ - 1) 个数字之内，则认为被视为 <= 最近接收到的序列号。这样的消息会被视为已接收消息的重复消息，并且在处理时会被忽略。
例如，当上一次接收 Ns = 0，此时收到 Ns = {[32769 - 65535]，[0]} 被视为收到重复消息。当上一次接收 Ns = 15，此时收到 Ns = {[32784 - 65535]，[0 - 15 ]}被视为收到重复消息。
3@：可靠传输必须确认重复消息的接收。此确认可以附在队列中的消息上，也可以通过 Zero-Length Body (ZLB) Message ACK 显式发送。同时，Zero-Length Body (ZLB) Message 中的 Ns 值不占用 sequence number 空间。因此，在发送 ZLB 消息后，Ns 不会增加。
4@：Nr 用于确认由 L2TP 对端接收到的消息。它包含对端期望下次接收的消息的序列号。虽然接收到 Zero-Length Body (ZLB) Message 中的 Nr 用于清除本地重传队列中的消息，但下一条发送的消息的 Nr 不会由 ZLB 的 Ns 更新。
5@：每个隧道维护一个控制消息队列，用于传输到其 peer。队列前面的消息会以给定的 Ns 值发送，并保持该状态，直到收到来自 peer 的控制消息，其中 Nr 字段指示已接收该消息。
6@：建议在 1s 内未收到自己发送消息的确认消息时，需重传该确认消息。重新传输的消息包含相同的 Ns 值，但 Nr 值必须更新为下一个预期消息的序列号。
tunnel timeout 用来配置 L2TP 报文的超时重传时间。默认 2s。
7@：需要多次重传时，每次重传的消息间隔必须采用指数退避间隔。也即每一次重传其时间间隔为上一次的两倍。重传的最大消息间隔必须不小于 8s。建议在 5 次内未收到来自 peer 的响应时，拆除隧道及其内的所有 session。
tunnel retransmit 用于设置 L2TP 报文超时重传次数。

Offset Size (opt)和Offset pad… (opt)：Size 长 16bits，Padding 长不确定。在数据消息中决定应在 L2TP Header 中偏移多少字节。

L2TPv2 控制消息示例
L2TPv2 数据消息示例。当未在 L2TP session 建立阶段协商 AVP type 39 = Sequencing Required AVP 时，L2TP 的数据消息往往不携带 Ns 和 Nr 字段。某些情况下可能带来无法接受的结果，详情可查看相关资料。
自动换行
在《RFC3931-Layer Two Tunneling Protocol - Version 3》中新定义了 L2TPv3 的 Header Formats。并且将 L2TP Header 分为了 L2TP Control Message Header 和 L2TP Data Message Header。其中 L2TP Data Message Header 由 Session Header 和可选的 L2-Specific Sublayer 组成。这里选择 UDP 承载下的 L2TPv3 Session Header 进行介绍。
自动换行
L2TPv3 Control Message Header：
Control Connection ID：32bits，控制连接的标识符。作用与用法和 L2TPv2 中 Tunnel ID 类似。在 L2TP 控制消息建立控制连接时通过携带 AVP type 61 = Assigned Control Connection ID 来通告。
自动换行
L2TPv3 Session Header over UDP：
Session ID：32bits，单独提供了所有进一步数据包处理所需的上下文。包括 Cookie 的存在、大小和值、L2 特定子层的类型以及正在隧道传输的有效 payload 类型。在 L2TP 控制消息建立控制连接时通过携带 AVP type 63 = Local Session ID AVP 来通告。
Cookie (optional，maximum 64 bits)：用于检查接收到的数据消息与由 Session ID 标识的 session 之间的关联。

2.2.L2TP控制消息的AVP

L2TP 控制消息主要通过 AVP 进行控制信息的交互，所有 AVP 都具有通用的格式。

L2TPv2 的通用 AVP Format：
在这里插入图片描述 M-bit：Mandatory-bit，强制位。用控制接收到未识别的 AVP 的实现行为。当收到 L2TP 数据消息中包含 M-bit 置位的不可识别 AVP 时，必须终止与该 L2TP 数据消息关联的 session。反之，当收到 L2TP 数据消息中包含 M-bit 置位的不可识别 AVP时，必须忽略该 AVP。
H-bit：Hidden-bit，隐藏位。用于识别在 AVP 的属性值字段中隐藏数据。

H-bit 只有在 LAC 和 LNS 之间存在共享密钥时才能设置。共享密钥与隧道认证使用的密钥相同。如果在任何 L2TP 控制消息中的 AVP 中设置了 H-bit，则消息中必须还存在一个 AVP type 36 = Random Vector AVP ，并且该 AVP 必须在第一个 H-bit 置位的 AVP 之前。
自动换行
隐藏 AVP 值需要经过如下几个步骤：
1@：将原始明文 AVP 封装入 Hidden AVP。
Length of Original Value 用于标识原始属性值的长度。Original Attribute Value 用于标识要被混淆的属性值。Padding 用于混淆被隐藏的属性值长度的随机附加字节。
2@：对 {2 字节 AVP Attribute number，共享密钥， AVP type 36 = Random Vector AVP 中携带的任意长随机向量} 进行 MD5 hash 计算。
3@：将 MD5 hash 值与 Hidden AVP Subformat 进行异或计算后放置在 Hidden AVP Attribute Value 字段中。
自动换行
使用 H-bit 的 AVP 示例。此处的 AVP 未进行进一步解析。
自动换行
tunnel avp-hidden 用于使能 AVP 的 H-bit 功能。仅在 L2TP 配置了隧道认证情况下，针对部分 AVP 生效。

rsvd：4bits，保留位。必须置 0，并当收到该字段置位的 AVP 时必须视为未识别 AVP。
Length：10bits，长度。整个 AVP 字段的长度，单位字节。不考虑封装情况下该字段最小取值为 6，最大取值为 1023。
Vendor ID：2 字节，企业私有标识码。主要用于允许企业私有定制 AVP，不使用时该字段可置 0。具体定义可参考IANA发布的《Private Enterprise Numbers》。

Attribute Type：2 字节，属性类型。与 Vendor ID 结合用于标识具体携带的特定属性。
Attribute Value：不定长，属性值。用于携带具体的控制信息。当 AVP 的 Length 字段取值为 6 时，也即不包含 Attribute Value 字段。
自动换行

2.2.1.Message Type AVP和Result Code AVP

AVP type 0 = Message Type AVP：
在这里插入图片描述 Message Type：2 字节，此 AVP 的 Attribute Value 字段。

实际上 Message Type 还可以分为 Control Connection Management、Call Management、Link Status、PPPoE Relay、Multicast Management、Failover Management 和 Access Line Information Attributes 等多种类型。隧道建立维护主要与 Control Connection Management 和 Call Management 相关。后文主要介绍与此两种过程相关的行为。

1@：此 AVP 必须是第一个 AVP，紧紧位于 Control Message Header 之后。
2@：此 AVP 的 M-bit 必须置位 1。H-bit 必须不置位。整个 AVP 长固定为 8 字节。
自动换行此处展示了属于 Call Management 的 CDN 消息， AVP type 0 = Message Type AVP 的 Message Type 14 标识携带 (CDN) Call-Disconnect-Notify。
后续章节将介绍属于 Control Connection Management 和 Call Management 类的消息有哪些。
自动换行上图展示了 AVP type 0 = Message Type AVP 中属于 Link Status 类的 Message Type 值。
AVP type 0 = Message Type AVP 的 Message Type 15 标识携带 (WEN) WAN-Error-Notify 消息属于 Link Status 类控制消息。WEN 消息是由 LAC 发送给 LNS 的 L2TP 控制消息，用于指示 WAN 错误状况。
AVP type 0 = Message Type AVP 的 Message Type 16 标识携带 (SLI) Set-Link-Info 消息属于 Link Status 类控制消息。SLI 消息是由 LNS 发送给 LAC 的 L2TP 控制消息，用于设置 PPP 协商的 Option。这些 Option 可以在通话期间的任何时候发生变化，因此 LAC 必须能够在活动的 PPP 会话中更新其内部通话信息和行为。

自动换行
AVP type 1 = Result Code AVP：(StopCCN，CDN，MSEN)

当 AVP type 0 = Message Type AVP 的 Message Type 4 标识携带 (StopCCN) Stop-Control-Connection-Notification、Message Type 14 标识携带 (CDN) Call-Disconnect-Notify 或 Message Type 27 标识携带 (MSEN) Multicast-Session-End-Notify 时，L2TP 控制消息还必须携带 AVP type 1 = Result Code AVP。

在这里插入图片描述 Result Code：2 字节无符号整型，此 AVP 的 Attribute Value 字段。
Error Code(opt)：2 字节无符号整型。可选的字段。
Error Message(opt)：不定长可选字段。Error Code(opt) 和 Error Message(opt) 由 AVP Length 字段标识用于共同携带以 UTF-8 编码的错误信息。

1@：此 AVP 的 M-bit 必须置位 1。H-bit 必须不置位。整个 AVP 长 8 字节时表示不存在 Error Code(opt) 和 Error Message(opt) 字段；长 10 字节时表示不存在 Error Message(opt) 字段；长 10 字节以上时同时存在 Error Code(opt) 和 Error Message(opt) 字段。
2@：此 AVP 需与 AVP type 0 = Message Type AVP 结合使用。当 AVP type 0 = Message Type AVP 携带的类型不同时，此 AVP 标识不同的 Result Code。
自动换行

当 AVP type 0 = Message Type AVP 的 Message Type 4 标识携带 (StopCCN) Stop-Control-Connection-Notification 时，AVP type 1 = Result Code AVP 中 Attribute Value 的 Result Code 字段有如下含义：
自动换行
当 AVP type 0 = Message Type AVP 的 Message Type 14 标识携带 (CDN) Call-Disconnect-Notify 时，AVP type 1 = Result Code AVP 中 Attribute Value 的 Result Code 字段有如下含义：自动换行
当 AVP type 0 = Message Type AVP 的 Message Type 27 标识携带 (MSEN) Multicast-Session-End-Notify 时，AVP type 1 = Result Code AVP 中 Attribute Value 的 Result Code 字段有如下含义：自动换行

3@：当发生与 L2TP 协议或消息格式错误相关的问题时，此时 L2TP 可通过发送 AVP type 0 = Message Type AVP 指示 Message Type 4 = (StopCCN) Stop-Control-Connection-Notification，并且通过 AVP type 1 = Result Code AVP 中 Result Code = 2 表明存在 General error–Error。此时，AVP type 1 = Result Code AVP 可以额外携带 Error Code(opt) 字段并标识具体的错误原因。
此处展示的即为相应的 Error Code(opt) 字段标识类型。

点击此处回到目录

2.2.2.Control Connection Management类AVP

在《2.2.1.Message Type AVP和Result Code AVP》中介绍 AVP type 0 = Message Type AVP 携带的 Message Type 字段值可以被分为几类，此处介绍 Control Connection Management 类 L2TP 控制消息中有可能出现的 AVP。

上图展示了 AVP type 0 = Message Type AVP 中属于 Control Connection Management 类的 Message Type 值。
Control Connection Management 类 AVP 主要用于 L2TP 隧道 Control Connection 的建立。

AVP type 2 = Protocol Version：(SCCRP，SCCRQ)
在这里插入图片描述 Ver：1 字节，version。
Rev：1 字节，revision。

1@：通常 {version 1，revision 0}，不同于 L2TP Header 中的版本。可以用于标识控制消息的版本。
2@：此 AVP 的 M-bit 必须置位 1。H-bit 必须不置位。

AVP type 3 = Framing Capabilities：(SCCRP，SCCRQ)
在这里插入图片描述 Reserved：14-bits，保留字段。
A-bit：1-bit，Asynchronous-bit。置位时表示支持 asynchronous framing。
S-bit：1-bit，Synchronous-bit。置位时表示支持 synchronous framing。

1@：不得在 incoming 或 outgoing call 中通告此 AVP。
2@：此 AVP 的 M-bit 必须置位 1。H-bit 必须不置位。

AVP type 4 = Bearer Capabilities：(SCCRP，SCCRQ)
在这里插入图片描述 Reserved：14-bits，保留字段。
A-bit：1-bit，Analog-bit。置位时表示支持模拟链路。
D-bit：1-bit，Digital-bit。置位时表示支持数字链路。

1@：此 AVP 的存在并不保证发送方在请求时一定能发起 outgoing call，只表明存在能力。
2@：此 AVP 的 M-bit 必须置位 1。H-bit 必须不置位。

AVP type 5 = Tie Breaker：(SCCRQ)
在这里插入图片描述 Tie Breaker Value：8 字节，用于在 LAC 和 LNS 同时请求同一隧道时选择单一隧道。此 AVP 出现于 LAC-LNS pair 场景下。

1@：AVP type 0 = Message Type AVP 的 Message Type 1 标识携带 (SCCRQ) Start-Control-Connection-Request 的接收方必须检查是否已经向对等方发送了 SCCRQ。

如果 LAC-LNS 都发送 SCCRQ，使用较低的 Tie Breaker Value 一方建立的隧道。
如果 LAC-LNS 都发送 SCCRQ，但 Tie Breaker Value 值相等，则双方都必须丢弃各自的隧道。
如果只有一方发起，则使用发起此 AVP 的一方建立的隧道。
如果双方都未发出决定器，则将打开两个独立的隧道。

2@：此 AVP 的 M-bit 必须不置位。H-bit 必须不置位。

AVP type 6 = Firmware Revision：(SCCRP，SCCRQ)
在这里插入图片描述 Firmware Revision：2 字节，用于封装供应商特有格式。如果不存在固件版本，则可以封装 L2TP 软件模块的版本。

1@：此 AVP 的 M-bit 必须不置位。

AVP type 7 = Host Name：(SCCRP，SCCRQ)
在这里插入图片描述 Host Name：不定长但至少为 1 字节。

1@：此 AVP 的 M-bit 必须置位 1。H-bit 必须不置位。
自动换行
tunnel name 用于在 LAC/LNS 上配置携带 AVP type 7 = Host Name 的内容。
allow l2tp virtual-template 1 remote 用于在 LNS 上设置来自 LAC 的 AVP type 7 = Host Name 内容。LAC 发送的 Host Name 需与 LNS 上配置的此命令指定的内容相同。

AVP type 8 = Vendor Name：(SCCRP，SCCRQ)
在这里插入图片描述 Vendor Name：不定长，必须以 UTF-8 编码的方式携带厂商字符串描述 LAC/LNS 类型。

1@：此 AVP 的 M-bit 必须不置位。

AVP type 9 = Assigned Tunnel ID：(SCCRP，SCCRQ，StopCCN)
在这里插入图片描述 Assigned Tunnel ID：2 字节，在 LNS 和 LAC 之间对多个隧道进行封装解封装。

1@：L2TP 收到此 AVP 后，必须在随后通过相关隧道传输的所有控制消息和数据消息发送的消息中 L2TP Header 的 Tunnel ID 字段中放置该值。
2@：当 AVP type 0 = Message Type AVP 的 Message Type 4 标识携带 (StopCCN) Stop-Control-Connection-Notification 时，此 AVP 必须与首次发送给对端时分配的 Assigned Tunnel ID AVP 相同。
3@：此 AVP 的 M-bit 必须置位 1。

AVP type 10 = Receive Window Size：(SCCRP，SCCRQ)
在这里插入图片描述 Window Size：2 字节。如果不存在，对方必须假设其发送窗口的窗口大小为 4。此 AVP 有利于设备处理乱序报文。

1@：此 AVP 的 M-bit 必须置位 1。H-bit 必须不置位。
2@：《RFC2661-Layer Two Tunneling Protocol "L2TP"的5.8.Reliable Delivery of Control Messages章节》中介绍在 SCCRQ/SCCRP 中，用于携带允许有最多 N 个未完成的控制消息。一旦发送了 N 个消息，它必须等待窗口前移的确认后才能发送新的控制消息。
3@：必须支持接收窗口为 4，允许仅支持接收窗口为 1。例如，在停止发送前能够发送 4 条消息。Window Size = 0 无意义。
自动换行
tunnel window receive 用来设置 L2TP 控制消息中 AVP type 10 = Receive Window Size 的值。

AVP type 11 = Challenge：(SCCRP，SCCRQ)
在这里插入图片描述 Challenge：不定长。当存在隧道认证时，可以出现此 AVP。

1@：此 AVP 的 M-bit 必须置位 1。
自动换行
tunnel authentication 和 tunnel password 用于共同配置 L2TP 隧道的认证功能。此功能需要 LAC/LNS 同时开启。
当仅 LAC 开启认证时，LNS 有可能不会回应来自 LAC 的 SCCRQ 消息。
当仅 LNS 开启认证时，LNS 可以回应 AVP type 0 = Message Type AVP 的 Message Type 4 标识携带 (StopCCN) Stop-Control-Connection-Notification 消息。
AVP type 11 = Challenge AVP 示例。

AVP type 13 = Challenge Response：(SCCCN，SCCRQ)
在这里插入图片描述 Response：16 字节，作为对 AVP type 11 = Challenge 的响应。

1@：当收到的 AVP type 0 = Message Type AVP 的 Message Type 1 标识携带 (SCCRQ) Start-Control-Connection-Request 或 Message Type 2 标识携带 (SCCRP) Start-Control-Connection-Reply 中携带 AVP type 11 = Challenge 时，则在对应的 Message Type 2 标识携带 (SCCRP) 或 Message Type 3 标识携带 (SCCRP) Start-Control-Connection-Connected 的回包中必须携带此 AVP。
2@：此 AVP 的 M-bit 必须置位 1。

点击此处回到目录

2.2.3.Call Management类AVP

在《2.2.1.Message Type AVP和Result Code AVP》中介绍 AVP type 0 = Message Type AVP 携带的 Message Type 字段值可以被分为几类，此处介绍 Call Management 类 L2TP 控制消息中有可能出现的 AVP。

上图展示了 AVP type 0 = Message Type AVP 中属于 Call Management 类的 Message Type 值。
Call Management 类 AVP 主要用于 L2TP 隧道 session 的建立。

AVP type 14 = Assigned Session ID：(CDN，ICRP，ICRQ，OCRP，OCRQ)
在这里插入图片描述 Assigned Session ID：2 字节，在 LNS 和 LAC 之间对 data 进行封装解封装。

1@：L2TP 收到此 AVP 后，必须在随后通过相关隧道传输的所有控制消息和数据消息发送的消息中 L2TP Header 的 Session ID 字段中放置该值。
2@：当 AVP type 0 = Message Type AVP 的 Message Type 14 标识携带 (CDN) Call-Disconnect-Notify 时，此 AVP 必须与首次发送给对端时分配的 Assigned Tunnel ID AVP 相同。
3@：此 AVP 的 M-bit 必须置位 1。

AVP type 15 = Call Serial Number：(ICRQ，OCRQ)
在这里插入图片描述 Call Serial Number：4 字节，为隧道两端的管理员提供一个便于参考的工具，用于调查呼叫失败问题。

1@：此 AVP 的 M-bit 必须置位 1。

AVP type 18 = Bearer Type：(ICRQ，OCRQ)
在这里插入图片描述 A-bit：1-bit，Analog channel bit。置位时表示呼叫涉及模拟信道。
D-bit：1-bit，Digital channel bit。置位时表示呼叫涉及数字信道。

1@：此 AVP 的 M-bit 必须置位 1。

AVP type 19 = Framing Type：(ICCN，OCCN，OCRQ)
在这里插入图片描述 A-bit：1-bit，Asynchronous framing bit。置位时表示同步帧。
S-bit：1-bit，Synchronous framing bit。置位时表示异步帧。

1@：此 AVP 用于表示 PPP frams 类型。
2@：此 AVP 的 M-bit 必须置位 1。

AVP type 22 = Calling Number：(ICRQ)
在这里插入图片描述 Calling Number 是一个 ASCII 字符串。用于描述 LAC 与 LNS 之间的联系。一种实现是可以携带用户对应的槽位接口等信息。

1@：此 AVP 的 M-bit 必须置位 1。
自动换行
undo l2tp calling-number-avp enable 和 avp calling-number disable 用于配置在 LAC 上发送 ICRQ 报文时，不携带 AVP type 22 = Calling Number。
calling-number-avp 用来配置在 LAC 上发送 ICRQ 报文时，AVP type 22 = Calling Number 封装格式为 radius 下发的 Calling-Station-Id。

AVP type 24 = (Tx) Connect Speed：(ICCN，OCCN)
在这里插入图片描述 BPS：4 字节，为连接尝试选择的设施速度。这个可选的 AVP 存在时表示从 LAC 的角度来看传输连接速度。

1@：此 AVP 的 M-bit 必须置位 1。

AVP type 37 = Private Group ID：(ICCN)
在这里插入图片描述 Private Group ID：不定长，用于表示此次呼叫与特定的客户组相关。

1@：LNS 可以根据对等方确定的特殊方式处理 PPP session 以及通过该 session 的网络流量。例如，如果 LNS 与使用未注册地址的多个私有网络分别连接，则 LAC 可以包含此 AVP，以指示某个呼叫应关联到其中一个私有网络。Private Group ID 是一个字符串，对应于 LNS 中的一个表，该表定义所选组的特定特性。LAC 可以根据 RADIUS 响应、本地配置或其他某些来源确定 Private Group ID。
2@：此 AVP 的 M-bit 必须置位 1。

AVP type 38 = (Rx) Connect Speed：(ICCN，OCCN)
在这里插入图片描述 BPS：4 字节，此 AVP 的存在意味着连接速度可能与 AVP type 24 = (Tx) Connect Speed 中给出的传输连接速度不对称。

1@：此 AVP 的 M-bit 必须置位 0。

AVP type 39 = Sequencing Required：(ICCN，OCCN)
此 AVP 不包含具体的 AVP Value 字段，LAC 向 LNS 通告的 AVP type 0 = Message Type AVP 的 Message Type 9 标识携带 (OCCN) Outgoing-Call-Connected 或 Message Type 12 标识携带 (ICCN) Incoming-Call-Connected 中携带此 AVP 时表明在进行数据转发时 L2TP Header 中必须携带 Sequence Numbers。

如果在 session 建立期间存在此 AVP，则 Sequence Numbers 必须始终存在。
如果在 session 建立期间不存在此 AVP，则 Sequence Numbers 的携带由 LNS 控制。LNS 通过在 session 生命周期内随时发送带或不带 Sequence Numbers 的数据消息来决定是否启用该功能。
因此，如果 LAC 收到不带 Sequence Numbers 的数据消息，它必须在之后的数据消息中不携带 Sequence Numbers。如果 LAC 收到带有 Sequence Numbers 的数据消息，它必须开始在之后的数据消息中携带 Sequence Numbers，Sequence Numbers 状态将从之前暂停的地方继续。

1@：此 AVP 的 M-bit 必须置位 1。H-bit 必须不置位。

AVP type 46 = PPP Disconnect Cause Code AVP：(《RFC3145-L2TP Disconnect Cause Information》，CDN)
在这里插入图片描述 1@M-bit：此 AVP 的 M-bit 必须置位 0。
2@Disconnect Code：2 字节，用于描述 PPP 断开连接的原因。
3@Control Protocol Number：2 字节，通常为 0。
4@Direction：1 字节，在特定 Disconnect Code value 下共同决定 PPP 断开连接的原因。

Disconnect Code value 0-4 属于 Global Errors；value 5-12 属于 LCP Errors；value 13-16 属于 Authentication Errors；value 17-20 属于 Network Control Protocol (NCP) Errors。其余值未具体定义其含义。此字段详细 value 的含义可查看 IANA 发布的《PPP Disconnect Cause Code (Attribute Type 46) Values》。
自动换行
tunnel avp46 用于在 LNS 上打开向 LAC 发送 CDN 消息时携带 AVP type 46 = PPP Disconnect Cause Code AVP。

2.2.4.Link Status类AVP

在《2.2.1.Message Type AVP和Result Code AVP》中介绍 AVP type 0 = Message Type AVP 携带的 Message Type 字段值可以被分为几类，此处介绍 Link Status 类 L2TP 控制消息中有可能出现的 AVP。

上图展示了 AVP type 0 = Message Type AVP 中属于 Link Status 类的 Message Type 值。
Link Status 类 AVP 主要用于隧道链路状态的通知。

AVP type 35 = ACCM AVP：(SLI)
在这里插入图片描述 LNS 使用 AVP type 0 = Message Type AVP 的 Message Type 16 标识携带 (SLI) Set-Link-Info 时，可携带此 AVP 用于向 LAC 通知 LNS 自己与 PPP peer 协商的 ACCM。
SLI 消息是由 LNS 发送给 LAC 的 L2TP 控制消息，用于设置 PPP 协商的 Option。这些 Option 可以在通话期间的任何时候发生变化，因此 LAC 必须能够在活动的 PPP 会话中更新其内部通话信息和行为。

Send ACCM：4 字节。LAC 应使用 Send ACCM 值来处理它在连接上发送的数据包。
Receive ACCM：4 字节。LAC 应使用 Receive ACCM 值来处理连接上接收的数据包。

1@：此 AVP 的 M-bit 必须置位 1。
2@：LAC 对这两个字段使用的默认值都是 0xFFFFFFFF。
自动换行
AVP type 35 = ACCM AVP 示例。
undo l2tp sendaccm enable 用于在 LNS 上关闭发送 AVP type 35 = ACCM AVP 功能。

2.2.5.ICCN消息中的代理认证AVP

当 AVP type 0 = Message Type AVP 的 Message Type 12 标识携带 (ICCN) Incoming-Call-Connected 时，还可能出现 Proxy LCP 和 Authentication AVPs。这些 AVP 主要用于描述 PPP 帧的协商信息。

AVP type 26 = Initial Received LCP CONFREQ：(ICCN)
在这里插入图片描述不定长，复制 LAC 初始收到 LCP message 中相应 option 向 LNS 传递。

1@：此 AVP 的 M-bit 必须置位 0。

AVP type 27 = Last Sent LCP CONFREQ：(ICCN)
在这里插入图片描述不定长，复制 LAC 发送 LCP message 中相应 option 向 LNS 传递。

1@：此 AVP 的 M-bit 必须置位 0。

AVP type 28 = Initial Received LCP CONFREQ：(ICCN)
在这里插入图片描述不定长，复制 LAC 最后收到 LCP message 中相应 option 向 LNS 传递。

1@：此 AVP 的 M-bit 必须置位 0。

AVP type 29 = Proxy Authen Type：(ICCN)
在这里插入图片描述 Authen Type：2 字节，用于 LAC 向 LNS 描述是否存在代理认证以及认证的类型。

1@：当存在代理认证时，Authen Type 字段所包含的含义。当存在代理认证时，Authen Type 字段所包含的含义。
2@：此 AVP 的 M-bit 必须置位 0。

AVP type 30 = Proxy Authen Name：(ICCN)
在这里插入图片描述不定长，用于描述需要认证客户端用户名。

1@：当消息中包含身份验证类型为 1、2、3 或 5 的 AVP type 29 = Proxy Authen Type 时，必须存在此AVP。
2@：此 AVP 的 M-bit 必须置位 0。

AVP type 31 = Proxy Authen Challenge：(ICCN)
在这里插入图片描述不定长，用于携带 LAC 向 PPP peer 发送的挑战字。

1@：当消息中包含身份验证类型为 2 或 5 的 AVP type 29 = Proxy Authen Type 时，必须存在此AVP。
2@：此 AVP 的 M-bit 必须置位 0。

AVP type 32 = Proxy Authen ID：(ICCN)
在这里插入图片描述 ID：1 字节，指定在使用代理认证时，LAC 与 PPP 对端之间启动的 PPP 认证的 ID 值。

1@：当消息中包含身份验证类型为 2、3 或 5 的 AVP type 29 = Proxy Authen Type 时，必须存在此AVP。
2@：此 AVP 的 M-bit 必须置位 0。

AVP type 33 = Proxy Authen Response：(ICCN)
在这里插入图片描述不定长，携带 LAC 从 PPP peer 接收到 PPP 认证响应。

1@：当消息中包含身份验证类型为 1、2、3 或 5 的 AVP type 29 = Proxy Authen Type 时，必须存在此AVP。
2@：此 AVP 的 M-bit 必须置位 0。

点击此处回到目录

2.3.L2TP协议的生命周期

在这里插入图片描述 L2TP 协议的全生命周期基本可以分为三部分：隧道控制连接和会话的建立、隧道上数据的转发和维护以及隧道控制连接和会话的拆除。同一对 LAC 和 LNS 可以共享相同的控制连接，并基于用户建立多个 session。

tunnel-per-user 用来配置在 LAC 上为每一个 L2TP 用户使用一条独立隧道。

随后的部分将介绍上述内容。

2.3.1.Control Connection和Session的建立

L2TP 协议控制连接的建立主要使用 Control Connection Management 类 L2TP 控制消息：
在这里插入图片描述 1@：在 L2TP 协议控制连接阶段并不严格定义发起方。控制连接阶段用于确认包括对端的身份，以及识别对端的 L2TP 版本、封装方式和承载能力等。
2@：L2TP 的隧道认证协议也发生在此阶段。要参与隧道认证，LAC 与 LNS 之间必须存在一个共享的密钥。这一行为主要利用 AVP type 11 = Challenge 和 AVP type 13 = Challenge Response 两种 AVP 来完成。

tunnel authentication 和 tunnel password 用于共同配置 L2TP 隧道的认证功能。此功能需要 LAC/LNS 同时开启。当仅 LAC 开始认证时，LNS 有可能不会回应来自 LAC 的 SCCRQ 消息。
AVP type 11 = Challenge AVP 示例。

一种典型的隧道认证交互如下：

控制连接的发起方首次发送 SCCRQ 进行连接请求时，携带 AVP type 11 = Challenge 进行请求认证。
控制连接的响应方回应 SCCRP 进行连接回应时，携带 AVP type 13 = Challenge Response 作为对控制连接的发起方挑战认证的结果回应。同时携带 AVP type 11 = Challenge 再次进行认证。
控制连接的发起方发送 SCCCN 进行连接时，携带 AVP type 13 = Challenge Response 作为对控制连接的响应方挑战认证的结果回应。

3@：当 Control Connection 的建立紧跟着 session 的建立时，L2TP 协议控制连接可以不发送 Zero-Length Body (ZLB) Message 直接进行 session 建立的信息交互。

1@：AVP type 0 = Message Type AVP 的 Message Type 1 标识携带 (SCCRQ) Start-Control-Connection-Request 消息，Message Type 2 标识携带 (SCCRP) Start-Control-Connection-Reply 消息，Message Type 3 标识携带 (SCCCN) Start-Control-Connection-Connected 消息。
2@：Zero-Length Body (ZLB) Message 主要用于显式消息确认，仅包含 L2TP Header 字段。
3@：详细的 Control Connection 状态机可查看《RFC2661-Layer Two Tunneling Protocol的7.2.Control Connection States章节》。
自动换行
ZLB Message 示例。

自动换行
L2TP 协议 session 的建立主要使用 Call Management 类 L2TP 控制消息：
在成功建立 Control Connection 后，可以创建各个 session。每个 session 对应于 LAC 与 LNS 之间的单个 PPP 用户流。并且 session 的建立存在方向性。

LAC 发起的 session 是 Incoming Call，LNS 发起的 session 是 Outgoing Call。
在这里插入图片描述需要注意的是 Incoming Call 由 LAC 发起，同时在进行请求确认后的连接消息由 LAC 发起。

当 LAC 检测到某些响应时，LAC 生成对应的 AVP type 0 = Message Type AVP 的 Message Type 10 标识携带 (ICRQ) Incoming-Call-Request 消息向 LNS 发送：
1@：ICRQ 必须携带 AVP type 14 = Assigned Session ID AVP 和 AVP type 15 = Call Serial Number AVP。
2@：ICRQ 可能携带 AVP type 18 = Bearer Type AVP、AVP type 22 = Calling Number Type AVP、AVP type 21 = Called Number AVP、AVP type 23 = Sub-Address AVP 和 AVP type 25 = Physical Channel ID AVP。
自动换行
当 LNS 选择接听呼叫，LAC 生成对应的 AVP type 0 = Message Type AVP 的 Message Type 11 标识携带 (ICRP) Incoming-Call-Reply 消息进行回应。：
1@：随后，LAC 会尝试连接呼叫向 LNS 发送 AVP type 0 = Message Type AVP 的 Message Type 12 标识携带 (ICCN) Incoming-Call-Connected 消息。
2@：如果呼叫在 LNS 接听之前终止或拨入客户端挂断时，LAC 将向 LNS 发送 AVP type 0 = Message Type AVP 的 Message Type 14 标识携带 (CDN) Call-Disconnect-Notify 消息。也就进入 session 拆除阶段。
自动换行
一旦 LAC 发起 Incoming-Call-Request 通常意味着过渡到 wait-reply 状态，但在某些情况下 LNS 不一定会回应呼叫：
1@：资源不足以处理更多的 session。
2@：拨号、正在拨号或 sub-address 字段与授权用户不符。
3@：提供的 bearer service 类型未经授权或不支持。
自动换行
详细的入向呼叫状态机可查看《RFC2661-Layer Two Tunneling Protocol的7.4.Incoming calls章节》。

在这里插入图片描述需要注意的是 Outgoing Call 由 LNS 发起，但在进行请求确认后的连接消息仍由 LAC 发起。

Outgoing Call 由 LNS 发起 AVP type 0 = Message Type AVP 的 Message Type 7 标识携带 (OCRQ) Outgoing-Call-Request 消息向 LAC 发送：
1@：OCRQ 必须携带 AVP type 14 = Assigned Session ID AVP、AVP type 15 = Call Serial Number AVP、AVP type 16 = Minimum BPS AVP、AVP type 17 = Maximum BPS AVP、AVP type 18 = Bearer Type AVP、AVP type 19 = Framing Type AVP 和 AVP type 21 = Called Number AVP。
2@：OCRQ 用于指示将为该呼叫在 LNS 和 LAC 之间建立 session，并向 LAC 提供有关 session 以及即将发起的呼叫的参数信息。LNS 必须在隧道建立过程中从 LAC 收到 AVP type 4 = Bearer Capabilities AVP，才能请求向该 LAC 发起 Outgoing Call。
自动换行
LAC 会以 AVP type 0 = Message Type AVP 的 Message Type 8 标识携带 (OCRP) Outgoing-Call-Reply 消息来回应 LNS 发送的 OCRQ：
1@：OCRP 必须携带 AVP type 14 = Assigned Session ID AVP。
2@：OCRP 用于表明 LAC 能够尝试外呼，并返回关于呼叫尝试的某些参数。
自动换行
LAC 发送完成 OCRP 后，会以 AVP type 0 = Message Type AVP 的 Message Type 9 标识携带 (OCCN) Outgoing-Call-Connected 消息再次向 LNS 发送：
1@：OCCN 必须携带 AVP type 19 = Framing Type AVP 和 AVP type 24 = (Tx) Connect Speed BPS AVP。
2@：OCCN 用于指示所请求的呼出呼叫的结果是否成功。它还向 LNS 提供有关呼叫建立后获得的特定参数的信息。
自动换行
详细的出向呼叫状态机可查看《RFC2661-Layer Two Tunneling Protocol的7.5.Outgoing calls章节》。

点击此处回到目录

2.3.2.隧道数据的转发和维护

1@：一旦隧道建立完成，来自远程系统的 PPP 帧将在 LAC 处接收，同时去掉 CRC、链路封装和透明字节后封装在 L2TP 中，通过相应的 L2TP 隧道转发。

2@：L2TP 隧道在转发 PPP 帧时，会在其 L2TP Header 中关联相应的 Tunnel ID 和 Session ID。

Tunnel ID 由 Control Connection 建立阶段确定，Session ID 由 session 建立阶段确定。
Tunnel ID 和 Session ID 为 0 属于特殊情况。通常 Tunnel ID = 0 仅发生在 Control Connection 建立的第一次报文交互过程，Session ID = 0 仅发生在 Control Connection 建立阶段和 session 建立阶段的第一次报文交互过程。

3@：给定的 LNS-LAC 对之间可能存在多个隧道，并且隧道内可能存在多个 session。

4@：L2TP Header 中还定义了可选的 Ns (opt) 和 Nr (opt) 字段用于提供可靠的控制消息传输。与 L2TP 控制通道不同，L2TP 数据通道不使用 Sequence Numbers 来重发丢失的数据消息，而可以用来检测丢失的数据包或恢复在传输过程中造成的乱序。

5@：如果在 session 建立期间，LAC 向 LNS 通告的 OCCN/ICCN 中携带 AVP type 39 = Sequencing Required AVP，则在 L2TP 隧道进行数据转发时 Sequence Numbers 必须始终存在。
如果在 session 建立期间中未携带 AVP type 39 = Sequencing Required AVP，则 Sequence Numbers 的携带由 LNS 控制。LNS 通过在 session 生命周期内随时发送带或不带 Sequence Numbers 的数据消息来决定是否启用该功能。

因此，如果 LAC 收到不带 Sequence Numbers 的数据消息，它必须在之后的数据消息中不携带 Sequence Numbers。如果 LAC 收到带有 Sequence Numbers 的数据消息，它必须开始在之后的数据消息中携带 Sequence Numbers，Sequence Numbers 状态将从之前暂停的地方继续。

6@：当一定时间内未收到来自 L2TP peer 的控制消息或数据消息时，可以通过发送 Hello 控制消息来探测 L2TP 隧道是否中断。

《RFC2661-Layer Two Tunneling Protocol的6.5.Hello章节》中认为
1@：L2TP Hello 消息是一种控制消息，其发送取决于 LAC/LNS 的本地机制。接收方会返回 Zero-Length Body (ZLB) Message 确认消息或携带必要确认信息的无关消息。
2@：协议推荐在 60s 内未收到任何来自对等方的消息时，发送 L2TP Hello 控制消息。
3@：L2TP Hello 控制消息中的 Session ID 必须为 0，并且必须包含 AVP type 0 = Message Type AVP。
自动换行
tunnel timer hello 用于设置 L2TP Hello 控制消息的发送周期。
L2TP Hello 控制消息示例。

2.3.3.Control Connection和Session的拆除

通常 L2TP Control Connection 和 session 的拆除都仅涉及一次报文交互。
在这里插入图片描述首先进行的是 session 的拆除：

LAC/LNS 中的一方首先发送 AVP type 0 = Message Type AVP 的 Message Type 14 标识携带 (CDN) Call-Disconnect-Notify 消息。该 L2TP 还必须包含 AVP type 1 = Result Code AVP 和 AVP type 14 = Assigned Session ID AVP，以标识 session 拆除的原因和哪一条 session 被拆除。
CDN 消息用于请求断开隧道中的特定呼叫，其目的是通知对端断开连接及断开原因。对端必须清理任何资源，并且不会回传任何成功或失败的指示。
LAC/LNS 中的另一方收到对方发送的 CDN 消息后，可以以 Zero-Length Body (ZLB) Message 进行回应。

当 AVP type 0 = Message Type AVP 的 Message Type 14 标识携带 (CDN) Call-Disconnect-Notify 时，AVP type 1 = Result Code AVP 的 Attribute Value 有如下含义：自动换行
由于 CDN 消息携带的 AVP type 1 = Result Code AVP 仅能描述 L2TP 取消连接的相关信息，在《RFC3145-L2TP Disconnect Cause Information》中又新定义了一种 AVP type 46 = PPP Disconnect Cause Code AVP。这种 AVP 可以进一步描述由 PPP 协议导致 session 拆除的原因：
1@M-bit：此 AVP 的 M-bit 必须置位 0。
2@Disconnect Code：2 字节，用于描述 PPP 断开连接的原因。其中，value 0-4 属于 Global Errors；value 5-12 属于 LCP Errors；value 13-16 属于 Authentication Errors；value 17-20 属于 Network Control Protocol (NCP) Errors。其余值未具体定义其含义。
此字段详细 value 的含义可查看 IANA 发布的《PPP Disconnect Cause Code (Attribute Type 46) Values》。
3@Control Protocol Number：2 字节，通常为 0。
4@Direction：1 字节，在特定 Disconnect Code value 下共同决定 PPP 断开连接的原因。
自动换行
tunnel avp46 用于在 LNS 上打开向 LAC 发送 CDN 消息时携带 AVP type 46 = PPP Disconnect Cause Code AVP。

自动换行
一旦 LAC 发起 Incoming-Call-Request 通常意味着过渡到 wait-reply 状态，但在某些情况下 LNS 不一定会回应呼叫：
1@：资源不足以处理更多的 session。
2@：拨号、正在拨号或子地址字段与授权用户不符。
3@：提供的 bearer service 类型未经授权或不支持。

自动换行
在这里插入图片描述在 L2TP 隧道所承载的所有 session 都被拆除后，可以进行 Control Connection 的拆除。

LAC/LNS 中的一方首先发送 AVP type 0 = Message Type AVP 的 Message Type 4 标识携带 (StopCCN) Stop-Control-Connection-Notification 消息。该 L2TP 还必须包含 AVP type 1 = Result Code AVP 和 AVP type 9 = Assigned Tunnel ID AVP，以标识隧道拆除的原因。
StopCCN 消息用于通知其对端隧道正在关闭，并且 Control Connection 应被关闭。此外，所有活动 session 会被隐式清除。StopCCN 消息没有显式回复，只有由可靠控制消息传输层接收到的隐式确认（ACK）。
LAC/LNS 中的另一方收到对方发送的 StopCCN 消息后，必须以 Zero-Length Body (ZLB) Message 进行回应。同时保持足够的控制连接状态，用于在 Zero-Length Body (ZLB) Message 丢失后再次进行回应。这一周期应至少大于通常的 StopCCN 消息发送周期。推荐的 StopCCN 重传周期为 30+1s。

当 AVP type 0 = Message Type AVP 的 Message Type 4 标识携带 (StopCCN) Stop-Control-Connection-Notification 时，AVP type 1 = Result Code AVP 的 Attribute Value 有如下含义：
自动换行

点击此处回到目录

3.L2TPv2实例

3.1.L2TPv2基本实例

本章内容仅作示例展示使用。个人能力有限，有问题可私信交流。

在这里插入图片描述这里以上图为例进行 L2TPv2 协议 Incoming Call LAC/LNS pair 交互场景下的配置介绍。

LAC 相关配置如下：

#sysname AR2
#l2tp enable
#
aaaauthentication-scheme l2tp-ddomain l2tp-dauthentication-scheme l2tp-dlocal-user pppoe-1@l2tp-d password cipher pppoe-1local-user pppoe-1@l2tp-d privilege level 15local-user pppoe-1@l2tp-d service-type ppp
#
interface Virtual-Template1ppp authentication-mode chap#
interface GigabitEthernet0/0/0pppoe-server bind Virtual-Template 1
#
interface GigabitEthernet0/0/1ip address 10.1.2.1 255.255.255.252
#
l2tp-group 1tunnel name LAC-AR2start l2tp ip 3.3.3.3 domain l2tp-d
#
ip route-static 3.3.3.3 32 GigabitEthernet0/0/1 10.1.2.2

LNS 相关配置如下：

#sysname AR3
#l2tp enable
#
ip pool l2tp-poolgateway-list 192.168.1.1 network 192.168.1.0 mask 255.255.255.0 
#
aaalocal-user pppoe-1@l2tp-d password cipher pppoe-1local-user pppoe-1@l2tp-d privilege level 15local-user pppoe-1@l2tp-d service-type ppp
#
interface Virtual-Template1ppp authentication-mode chap remote address pool l2tp-poolppp ipcp remote-address forcedppp ipcp default-routeppp timer negotiate 5ppp ipcp dns 8.8.8.8 114.114.114.114ip address 192.168.1.1 255.255.255.0 
#
l2tp-group 1undo tunnel authenticationallow l2tp virtual-template 1 remote LAC-AR2tunnel name LNS-AR3
#

需要说明的是：
1@：此处的 domain 配置实际上是以本地认证的方式存在。当存在 RADIUS 时，可以指定 domain 认证方式为 RADIUS 认证。此时 RADIUS 可以向用户下发对应的用户属性。
2@：此外，仍可以支持对 L2TP 功能的更精细配置。例如，L2TP 报文处理数、单板 L2TP 会话数、TCP MSS、MTU 等参数。

3.2.L2TPv2协议交互及状态查看

1@：当用户上线时，首先触发的应当是 PPPoE 发现过程。这一过程依次经历了 PADI、PADO、PADR 和 PADS。在通过 PADS 获取到 PPPoE 唯一的 Session ID 后，随后进入 PPP 的交互流程。

关于 PPPoE 交互的详细原理，可查看《博客-PPPoE协议个人理解+报文示例+典型配置-RFC2516》。

2@：PPP 的交互流程可分为 LLCP/LCP 数据层控制协议发现、NCP 网络层控制协议交互以及最终的数据流程交互。
LLCP/LCP 包含数据链路的发现，MTU 的协商以及 PPP 认证过程。在 LLCP/LCP 完成 CHAP 认证后，同时触发 L2TP 隧道的 Control Connection 和 Session 的建立。