在添加 OTV 之前，写下你需要的 Ethernet 合约

一个工作负载搬到第二个数据中心，并开始在第一个数据中心本来响应正常的服务上超时。有人提议 OTV，理由是现有 Layer 2 VPN「不做广播」。这个结论通常下得太早。服务类别和你实际购买的那份合约是两个不同的问题，而超时还没有归因于其中任何一个。

引发比较的症状

在比较产品之前，先写下应用真正需要什么。站点数量、VLAN 范围、地址学习、泛洪容忍度和故障行为描述的是需求。「Layer 2」和「OTV」描述的是架构，两者本身都不是需求。一页纸上的五条属性，比任何厂商对比都更长久。

然后检查现有服务是否已经满足这五条属性。由运营商管理的 Layer 2 VPN 可能包含多点转发和控制平面学习，而快速扫一眼账单并不会提到这些。

如果现有服务确实满足，那么超时在别处：MTU 问题、路由不对称、站点之间不同的防火墙规则。更换 overlay 会让这个原因继续存在，并额外增加一次迁移。

Layer 2 VPN 是一个类别，不是产品。点到点的 VPWS 和多点的 VPLS 转发方式不同，这个类别既包括带控制平面学习和环路管理的服务，也包括更简单的服务。假设每个 Layer 2 VPN 都恰好连接两个站点并泛洪一切，正是做出错误比较的方式。合约上的名称对背后的转发表只字未提。

问一问现有服务实现的是哪种转发模型，以及应用需要哪一种。中心辐射型需求和全网状需求会产生不同的设计，即使两者都被描述为 Layer 2。

OTV 运行在 IP 传输之上，具有控制平面的 MAC 可达性和明确的边缘角色。本地生成树信息留在本地，而不是作为一个不受控的域跨越传输扩展出去。这与简单的桥接扩展有实质区别，也正是人们求助于它的原因。

边界和收益同样重要。未知的单播、广播和组播处理取决于平台及其配置，一对边缘设备必须通过受支持的多归属机制协同工作。两台独立设备转发同一个 VLAN 并不是同一种设计，会产生不同的故障模式。

抑制一部分不必要的泛洪，并不等于保证没有任何广播或组播帧会越过扩展。在一个站点开始的广播风暴仍然可能吞掉传输，而过滤某一类流量的平台功能并不会过滤其他类别。任何 overlay 的大多数失望都来自这个区别。

所以问题不是 OTV 是否阻止广播风暴，而是哪些流量类别会通过、在什么条件下通过，以及通过时什么在限制速率。

趁你在现场时确认底层：受支持的交付、报文大小、路由，以及所选版本要求的邻接关系。这些都不会随 overlay 免费附送，一条能容纳 1500 字节帧的隧道，并不自动就是能容纳你带标签帧的隧道。

无论你选择哪种服务，都要求同样的六个答案：点到点还是多点范围、客户帧和标签的处理、MAC 学习模型、泛洪限制、恢复行为，以及端到端的最大帧大小。两个同名的服务可能在每一条上都不同。务必拿到书面答复，因为配置服务的那位工程师未必就是回答问题的人。

只为现有服务明确无法满足的需求选择变更。进一步扩展 VLAN，也会把应用和 Ethernet 的依赖一并扩展；新的 overlay 名称并不会消除它们。

RFC 4664 框架阐明了服务类别及其转发模型，这正是提出正确问题所需的词汇。把六个答案和失败的测试带到同一个会议上，决定就不再是关于标签的了。