L2TPv2、L2TPv3、GRE 与 VPWS：按有效载荷选择

多数L2TP 与 GRE 之争都会以同样的方式瓦解：这些名称处在问题的不同层次上。其中两样描述的是你在自己的路由器上配置的封装。另一样描述的是别人卖给你的服务。从端点必须承载的有效载荷出发，比较就会变成一份简短的结果清单，而不是一场功能之争。

先看有效载荷，再看协议

实践中，有效载荷是四种东西之一：PPP 会话、原始以太网帧、IP 数据包，或交给服务商的 MPLS 帧。每一种对寻址、广播处理和故障检测提出的要求都不同。这份清单搞错了，再多的封装调优也救不了设计。

这些行之外的东西都是后加的，例如加密、压缩或流量整形。先选行。

L2TPv2 与 L2TPv3 只共享一个名字，其余几乎毫无共同点

L2TPv2 的存在是为了在 IP 网络上承载 PPP 会话，所以它读起来更像远程接入协议，而不是通用的帧传输。L2TPv3 把这一思路一般化：一条控制连接协商会话，每个会话在两条 IP 端点之间承载一条确定的第 2 层连接。同样的家族名，不同的控制协议，不同的会话模型。只写 L2TP 的需求是不完整的，而从错误版本抄来的模板甚至无法协商。

如果需要 PPP，L2TPv2 是该家族中唯一现实的选择；如果需要跨路由核心的以太网帧，你就在 L2TPv3 的地盘上。

传输细节的差异会在防火墙审查中暴露出来。L2TPv3 可以直接走 IP 协议 115，也可以封装在 UDP 内，通常是 1701 端口；而 L2TPv2 始终走 UDP 1701，内部是 PPP。为其中一个版本写的策略看起来完全正确，却可能放行不了另一个。

GRE 是一个头部，不是一种服务

GRE 用带可选密钥和序列字段的四字节头部包裹有效载荷，然后把结果交给 IP 投递。它不声明有效载荷意味着什么，因此只要设备支持，实现就可以隧道化 IPv4、IPv6 或以太网。通用不等于普适：要在真实设备上核实协议类型和分片行为。

密钥字段正是 GRE 在多条隧道共用一对端点地址时有用之处，因为接收方按该值解复用。IPv4 上的 GRE 在任何额外选项之前约占用 24 字节，这在已经按 1500 字节帧规划的链路上开始变得重要。单凭 GRE 不提供机密性，所以常见做法是把它与 IPsec 配对，让 IPsec 负责加密边界。这种配对可行，但 MTU 预算必须同时覆盖两个头部。

当有效载荷是以太网时，GRE 还能把组播和广播带过隧道，这是普通单播 IP 隧道做不到的。设计选择它，通常是因为这个特性，而不是因为缩写。

VPWS 是买来的，不是配出来的

虚拟专用线服务通过服务商网络提供一条点对点的第 2 层电路。你的接入电路终结在服务商的边缘设备上，穿越核心的伪线归服务商所有。真正重要的问题是运营层面的：分界点在哪里，第一英里和最后一英里归谁，以及服务商如何处理超大帧。

比较在这里转向。L2TPv3 和 GRE 是你端到端自己运营的东西，所以用自己的凭据和自己的抓包去调试它们。VPWS 是一份带交付的合同，所以故障从工单开始，而不是从抓包开始。没有哪种模型稳赢；它们失败的地方不同，选择取决于你是否愿意拥有最后一英里。

伪线的标签栈留在服务商网络内部，所以它不会像可见的隧道头部那样改变你的 MTU 计算。

选一行，写下来

把决定记成一句话，包含三部分：有效载荷、封装和传输归属方。然后附上让它可核查的数字。

对每个候选方案，写下链路上的开销、路径能接受的最大帧，以及第一个会报告 MTU 问题的跳。确认两端都支持你选的协议类型或会话类型，而不只是数据表上的营销词。想清楚明年出现第二条电路时复用会是什么样，因为 GRE 密钥和 L2TPv3 会话 ID 并不是这个问题的可互换方案。然后发一个超大帧和一个正常帧；这一对能抓住大多数纸面上看起来没问题的设计。

按名称比较隧道，只会不断产生没人能解决的争论。按有效载荷、开销和归属来比较，一个下午就能得出结论，还附带日后为它辩护所需的证据。