L2VPN、VPLS、EVPN：名称并不是服务

你在一份报价上读到“L2VPN”，又在配置表上看到“VPLS”，就以为后一个词是对前一个词的收窄。有时确实如此，有时这两行回答的是毫不相关的问题。真正的误解，是把这些名称当成从入门到进阶的阶梯。L2VPN 是一个家族，VPWS 与 VPLS 是其中两种服务行为，而 EVPN 是一种能承载前两者的控制平面机制。

每个缩写回答的是不同的问题

从客户接入点必须完成什么开始，因为这是服务模型唯一回答的问题。两个站点之间的点到点电路，与横跨十个站点的共享以太网段，是不同的产品，即使两者都以第 2 层连接的名义出售。

那张表不是层级结构，把它当层级来读，就会犯下采购中最常见的错误：拿 VPWS 报价去比 VPLS 报价，仿佛后者是前者的更完整版本。它们解决的是不同问题，按买家通常假定的意义，谁也不是谁的超集。

VPWS 与 VPLS 在转发决策处分开

在虚拟专线服务中，接入点选择远端端点。到达该端口的流量朝配对端口发出，而提供商边缘在做基础转发决策时，并不需要学习它背后有哪些 MAC 地址。

在 VPLS 中，提供商边缘执行桥接。它会检查每一帧的目的 MAC 地址，按接入点学习源地址，并在仿真 LAN 内泛洪未知目的。这既让服务表现得像 LAN，也正是运行限制的来源。

一张看起来是多点的拓扑图，并不能证明所有站点共享同一个广播域。两家提供商可以画同一朵云，却分别卖一个桥接域或若干条点到点电路，而这个差别只有在一帧广播、一帧未知单播，或一次 MAC 迁移跨过站点边界时才显现。两个站点之间做一次广播 ping，比任何架构幻灯片都更快地回答这个问题。如果每个其他站点都应答，你拥有的是一座桥；如果只有那一对站点应答，你拥有的是一根线。

EVPN 是控制平面，不是拓扑

EVPN 的基础规范 RFC 7432 定义了基于 BGP MPLS 的以太网 VPN 流程：MAC 可达性在 BGP 中通告，而不是只靠数据面泛洪学习。随后 RFC 8214 规定了用 EVPN 承载 VPWS 的方式，正是这一点打破了阶梯模型。同一个控制平面既服务于点到点业务，也服务于多点业务。

所以“我们跑 EVPN”并不是对“我们买了什么”的回答。提供商仍要说清：这项服务是一对接入点，还是一个共享桥；承载是 MPLS、VXLAN 还是别的东西。这些选择活在不同的文档里，也活在同一份配置的不同部分。

对运营商来说，实际的后果是：早一点选择 EVPN，会让日后的业务变更更便宜，因为可达性已经是通告出来的，而不是泛洪出来的。它并不能免除先决定服务模型这一步，也不会把一个配错的桥变成对的。

MPLS 是数据通路，不是定义

框架文档描述的是这个家族及其要求；它们并不要求某一种封装。MPLS 标签栈是这类服务的常见承载，但并不是唯一的一种。由 BGP 通告的服务与 MPLS 转发路径是两个彼此独立的设计决定，只是经常一起出现。

当供应商说“MPLS L2VPN”时，先问描述的是哪一半。如果答案只有承载，服务模型仍然没有确定，接入行为也仍然未知。

把名称变成合同的四个问题

问交接是什么：一个端口、一个 VLAN，还是一组 VLAN，其中哪些彼此可以通信。问各站点是否共享同一个广播域，因为仅仅这一个答案就决定了泛洪、MAC 上限，以及环路的走向。

问端到端的帧长预算，然后自己把封装开销加上去。问当一条接入失效时会发生什么：其余的是否继续转发，提供商是撤销可达性，还是留到一个定时器到期。

把这四个答案写在记录里产品名称的旁边。当下一次带着另一个缩写、同一个价格的报价到来时，比较就变成了对行为的比较，而只有这种比较才能预测网络在糟糕的那一天会怎么表现。