Traffic Trombone
创建DCI过程中以太网面临的另一种挑战是“Traffic Trombone(网络内部的信息往返流动)”(图3)。以在线商务为例： 它有面向公众的Web/应用服务器，该服务器可连接至内部数据库服务器。假设，有一个VLAN已被扩展到第二个数据中心。
如果该Web服务器在两个数据中心间徘徊，它会保留相同的IP地址，所有数据都必须穿过DCI链接。如图3所示，里面包括了出入外部用户端的数据以及出入数据库的数据。
另需增加的带宽严重限制了该方案的可扩展性而且还增加了带宽的成本。供应商正推出DNS负载平衡之类的传输系统，因为这样的系统可以随时将数据流发送到新地址，不过它们的实用性还不足。例如，如果你的数据库没有用类似Web服务器这样的监管平台进行虚拟化，你如何能对推动数据库服务器及其相关应用和Web服务器机制进行管理呢?
▲
阻止循环
以太网为DCI的创建带来了另一个技术性障碍。以太网创建于30年前，是一种本地网络协议，所以当时没有考虑到跨机器扩展。就设计而言，以太网是一种多路存取技术，所以可通过网络上的所有端点接收以太网广播和多点传播帧。
因此，当主机发送以太网广播或多点播帧时，这个帧必须通过所有以太网进行转发，包括DCI。当广播帧循环回到以太网网络时，它就会被所有交换机转发，即便它此前已被广播。这就制造了一种快速消耗所有网络带宽的条件，而结果便是导致网络瘫痪。
数年前开发的生成树协议就是为了阻止这种循环，而且它现在仍在沿用，尽管Rapid Spanning Tree Protocol (RSTP)已经在可靠性和速度方面有所超越。
问题是Spanning Tree不能在长距离传输中效果不好。当网络延时超过250毫秒时，RSTP就不再能阻止循环。
结论便是Spanning Tree不能在创建DCI时有效阻止循环。试一下你就会发现它易受单向数据流的影响，而其他操作都会出现故障。虽然存在单向链路检测协议(UDLD)这样的补丁，但是运营商的服务很有可能会拦截UDLD或是其他减少STP限制的功能。
供应商开发出了很多技术复杂的方案用于解决循环问题。三种最常见的方案就是VPLS，MLAG/PortChannel和OTV。
