通过光纤连接远程站点：第2层vlans还是第3层路由？

现在我们在两个地理上分开的站点之间有一个光纤束。 这是我们自己的“拥有”纤维，所以中间人不担心…此外，光纤环包括多个冗余，包括单独的物理path。 一切顺利。

鉴于此，在远程站点之间使用路由和不同子网仍然被认为是“最佳实践”？ 或者我们可以将我们的“本地”（主站点）networking与主站点vlans一起扩展到远程站点吗？ 这仍然被认为是不理想的，甚至是不好的做法？ 更重要的是，有什么理由不这样做？ （另外，我理解“反铲中断”问题，预计单独的物理path可以处理这种意外情况）。

首先，在这种情况下，没有最好的做法。 诸如layer2 / layer3站点互连的大图devise细节是由业务需求，预算，员工能力，您的偏好和供应商的function集驱动的。

即使在数据中心之间移动虚拟机实例的愿望（数据中心之间的Layer2互连要容易得多），我个人仍然尝试连接第3层的build筑，因为第3层链接通常意味着：

1. 降低运营成本，缩短问题解决时间。 绝大多数networking故障诊断都基于IP服务。 例如， mtr只具有三层可见性。 因此，当您发现数据包丢失时，由于拥塞或链路上的错误，第3层跳数更容易修复。 在处理多path问题时，Layer3也更容易诊断（例如，与非Layer3多path（例如LACP）进行比较）。 最后，当您可以直接跟踪边缘交换机时，更容易find服务器或PC的位置。

2. 较小的广播/洪泛域。 如果你的ARP / CAM定时器不匹配 ，你很容易受到未知的单播泛滥。 这个问题的解决方法是众所周知的，但是我所看到的大多数networking都不会妨碍ARP和CAM定时器的匹配。 最终结果？ 在二层域内发生更多的stream量突发和洪水……如果你通过build筑物间的二层链路泛滥，你就会淹没自然networking拥塞点。

3. 更容易部署防火墙/ ACL / QoS …所有这些东西都可以在第二层工作，但是它们往往在第三层更好地工作（因为在过去的20年中，供应商/标准组织至less花费了15年的时间， 。

4. 减less生成树。 MSTP / RSTP使生成树更加容忍，但是在STP阻塞链路上丢弃BPDU时，所有types的STP仍然归结为喜欢泛滥的恶意协议广播错误的方向。 什么时候可能发生？ 拥塞严重，碎片状的收发器，单向的链接（无论出于何种原因，包括人为的），还是运行错误的链接。

这是否意味着在build筑物之间部署layer2是不好的？ 一点也不…这实际上取决于你的情况/预算/工作人员的喜好。 不过，除非有另外的强制性原因，否则我会使用layer3链接。 ¹这些原因可能包括您的员工中的宗教偏好/pipe理层，对第三层configuration的熟悉程度较低等等。

^1如果有人想知道当数据中心之间存在三层链路时如何处理二层数据中心互连，如果没有Nexus设备，我更喜欢EoMPLS伪线。 理论上来说，如果我有Nexus，OTV似乎是一个候选人，但我个人还没有去过那里。 底线，当你必须的时候，有一些解决scheme可以将Layer2到Layer3隧道化。

这是一个艰难的，因为这两种方法都有优点和缺点。 在我以前的生活中，我的工作职责涉及更多的networkingpipe理，而不是系统pipe理，我们可能在12英里宽的地理区域内有二十多个网站。 这些站点中有一半被configuration为路由回到主办公室的另一半站点，另一半站点被configuration为“二层”站点（即，我们只是将VLAN扩展到该站点）。

“第二层”网站的优势在于它们的设置和维护要简单得多， 没有路由器需要，没有更新我们的静态路由，没有DHCP中继，没有单独的VLANconfiguration等。 我遇到的主要缺点是非技术性的，例如当你的广播域位于相距几英里的12个不​​同的build筑物中时，定位一个stream氓DHCP服务器就更困难了。 如果缺less不同站点的networking划分，许多pipe理任务就会变得更加棘手，例如Office A和Office B的不同防火墙规则，而不是Office C的规则在共享同一个VLAN /子网时比较困难。 我想你也可能遇到一个广播问题，这取决于你有多less设备，但是现在的交换技术是什么，你可以把一个数量惊人的主机塞进一个广播域，然后才真正成为一个问题。

“Layer-3”网站的优点与“Layer-2”网站大相径庭。 你会得到划分，你可以写每个站点的防火墙规则，你知道该死的Linksys路由器在哪个特定的build筑物。缺点显然是所需的设备进行路由和必要的configuration和维护。 dynamic路由协议和像VTP这样的东西（如果你敢用的话）可以减轻configuration的负担，如果你的networking是复杂的。

我的非答案答案：不要不必要地进行划分（即抵制诱惑过于聪明），但不要让短期的简单解决scheme胜出，更有意义的是有单独的VLAN /子网。 作为一个追逐我的Linksysstream氓DHCP服务器…呃“路由器”的人…我认为每个build筑物networkingdevise一个VLAN /子网是一个很好的例子，只是为了限制这些错误configuration可以做的损害。 另一方面，如果你只有两个站点，而且他们就在隔壁，那么他们共享相同的VLAN /子网是有意义的。

正如很多人所说，L2和L3解决scheme都有不错的优势。 早些时候我受雇于一家电话公司，我也一直在帮助小型networking开始。

如果一切正常，L2解决scheme更容易理解和便宜。 工作部分通常由重新连接他们认为被意外断开的电缆所毁坏。 环路保护和生成树可能是有用的，但最有可能造成更多的伤害比使用。

根据我的经验，L3解决scheme已经被我帮助过的各方更难理解了。 如果硬件和软件必须得到制造商的支持，成本也可能成为一个问题。 Linux上的x86机器是一个非常经济实惠的function填充路由器。

L3解决scheme的好处是环路和其他广播包含在一个更小的域内。 最好的例子是，如果有人在多个路由分支机构中的一个意外创build一个循环，只有该办公室消失，而其他人可以继续工作。

我投了一个L3路由解决scheme，主要是因为广播域较小，但也因为交通可以优先和防火墙容易。 如果有人需要L2连接，他们可以通过路由networking对他们进行隧道传输，甚至可以根据需要自行encryptionstream量。

我会推荐以lan速度路由的layer3交换机。 如果您拥有良好的光纤，那么可以使用这些设备在光纤上运行千兆networking，并仍然从路由networking（减less的广播域，访问列表等）中受益。

我认为，路由是一个最好的select。 如果光纤断裂，整个networking将崩溃。 如果使用CEF或类似的东西，使用第3层交换机（第3层交换）的路由就像第2层交换一样快。