FWIW 我已经在 TOR 设置中大规模使用 3750（3750G，然后是 3750E/3560E）；最初使用 L2 端口通道/GLBP（2x1G 和 2x2G 以及罕见的 2x4G 用于 db 机架），然后使用 L3 到 TOR（用于 3750E/3560E 和 10G 到核心）。我说的是成千上万。我们只看到问题与缓冲区最带宽密集型服务，在这一点上，我们正在寻找在10G到主机反正（和密集的比萨饼盒子24-48 SFP +的）。

您是否能够向管理层证明任何事情实际上取决于应用程序，并且您根据设计和应用程序的要求做功课，并确切知道应用程序的规范是什么，以及它的预期增长速度。与您的管理链以及网络的主要所有者/客户进行设计审查。

管理层想要查看数据，如果你没有资源来全面测试这个盒子（提出一个测试计划，将它连接到一些流量生成硬件，完全确定它的范围并根据设计规范对其进行压力测试，等）这将很难做到。他们不会对轶事证据印象深刻，找到这种硬数据可能会很困难，因为我敢肯定，发布这种东西的人会违反各种 NDA。

对此发布答案的其他所有人都很好地概述了 3750 平台的“问题区域”：它固有的堆叠和奇怪的故障模式、缓冲区大小等。还有这个问题概述了收集有关输出队列丢弃的 SNMP 统计信息的问题- 缓冲区在 ASIC 之间共享，因此您通过 SNMP 获得的任何统计信息对于特定端口范围都将相同（这可能是您可以在管理链中提出的一个症结点）。

总而言之，我会说 3750/3560 对大多数部署来说都“很好”，即使是在某种程度上也是如此。如果可以，请避免堆叠它们，但我想说以非常小且易于管理的数量进行堆叠并不太可怕。

这实际上取决于您的部署方案。3560/3750s 是很棒的交换机，有不错的缓冲区，而且它们通常适用于大多数应用程序。如果您的数据中心看到需要更大缓冲区的流量，您应该能够从交换机中提取统计信息，例如缓冲区使用情况和数据包丢失。说服管理层丢弃正在丢弃数据包的交换机应该不是一个太大的挑战。我认为。

在3750的早期，尤其是2010年左右之前发布的堆叠技术，交换机故障导致堆叠以不那么优雅的方式出现故障的问题很多。再加上升级堆栈并不是最直观的过程（从那时起它就得到了改进），3750 的名声真的很差，从那时起就一直存在。

在小型数据中心，3750 堆栈代表了一种相对低成本的选择，可以在无需机架式交换机成本的情况下获得端口密度。我自己刚刚为一个较小的客户安装了一个数据中心解决方案，该解决方案涉及一些带有 Netapp FAS2240 的 Cisco UCS C220 M3 服务器，我使用了 3750 的堆栈为每个新设备以及他们所有的旧服务器提供多机箱以太网通道冗余在过渡期间。它工作得非常非常好。

那么 - 3750 有问题吗？可能与已经存在了很长时间的任何其他开关相同。6500 在其生命周期的早期就出现了问题，现在它已经推出多年，而且还不错。我建议查看您将要投入的内容，如果性能指标成立，那么请确保您警惕地监控他们的性能。

老实说，我见过 3750 出现故障的最常见方式是将核心交换机升级到 Nexus 7k。通常（但不总是）更新的一部分是将 TOR 移至 Nexus 2000 FEX 或 Nexus 5000s。

尽管 3750 没有最大的缓冲区，但在大多数人看来，它们在大多数企业 DC 环境中“足够好”。

除非您可以为 DC 中的 3560/3750 所引起的问题付出一美元的代价，否则我怀疑您是否能够说服管理层在常规产品更新周期之外更换它们。