您如何说服管理层3560/3750在您的DC中是个坏主意？

3560 / 3750s的缓冲器很小，可以用来做壁橱开关。但是，我经常看到这些开关位于DC中。许多人倾向于使用它们，因为它们通常具有1Gb和L3功能。

有没有办法证明它们在DC部署中有多严重？我经常听到人们说他们尽快删除了3750，但是我还没有听到实际的故障情况，该情况可用于让管理层知道将其撤出。

FWIW我曾经在TOR设置中大规模使用过3750（3750G，然后是3750E / 3560E）。最初使用L2端口通道/ GLBP（2x1G和2x2G的变量以及用于db机架的罕见的2x4G），然后使用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 5000。

即使3750的缓冲区没有最大，在大多数人的脑海中，它们在大多数企业DC环境中也能“足够好”地工作。

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

@mellowd当然是正确的，这些开关不是非常有用的DC开关，因为它们的缓冲区非常有限，它们会微爆发并丢弃流量。

考虑您有2 * 1GE入口和1 * 1GE出口。最坏的情况是，在同时发送入口端口2毫秒后，出口端口开始下降。最好的情况是，您可以处理8ms突发。

每4个端口有2MB的出口缓冲区，因此2MB /（1Gbps / 8）=最大值16ms和16/4 = 4ms最小值。用该数字除以要发送的入口端口数量，就可以得到可以处理多长时间的数字。也就是说，您添加的入口端口（服务器）越多，您可以处理的微脉冲就越少。

如果必须使用3750/3560，则应阅读此文档以最大程度地使用缓冲区。而且，即使您的图表显示平均出口需求非常低，也要在出口处使用LACP。

为了向您的管理者证明缓冲区不足，无法监视/窃听/跨越当前网络切换所有下行链路，那么您将拥有时间戳和要发送的数据包大小，并且可以计算出瞬时需求超过1Gbps的数量以及多少缓冲，您将需要处理它。

性能当然是一个重要的问题，上面已经很好地解决了，但是基于功能和功能集还存在很多差异：

1. 在许多安装中，对外部RPS单元的需求是一个巨大的问题– 1U交换机在初始成本，空间损失和持续管理方面变得更加昂贵。在最小的数据中心环境中，冗余电源应被视为绝对必须的。

2. 最终用户连接的大量不必要的代码正在运行–出现缺陷，安全问题和停机的机会更多。

3. DC功能（ISSU，DCB，存储，某些内置脚本元素）不在（也不会在）以校园为中心的设备上使用。DC产品之外的当前状态和路线图也往往缺少以合理的方式管理和扩展L2扩展的机制（即FabricPath / TRILL，OTV，VXLAN等）。此处的列表只会增加-现成的虚拟化，硬件辅助机制的支持等。

4. 可扩展性–您如何发展基础架构？很多很多的开关（管理昂贵）？堆叠（操作困难，主要的布线问题）是一团糟。另外，在密度方面接口类型（例如，光纤与铜）的灵活性可能具有挑战性。

通常，DC和壁橱切换之间的差异正在增长。在思科世界中，出于非常充分的理由，存在不同的操作系统（NXOS与IOS）–千差万别的要求产生了不同的解决方案。数据中心不需要用户身份验证机制（802.1x）或功能强大的AV集成的功能速度，而布线室则不需要端接10GE吨的功能。用于不同工作的不同工具。连接台式机的Nexus盒也不太理想。

我还将向您指出各种设计指南（CVD等），这些指南列出了网络中各个点使用的交换机类型的基本原理。对于通常类似于行业最佳实践的解决方案，有话要说，而且您提到的交换机在DC中通常没有位置-除了管理网络或某些特殊情况下的本地连接情况。

我有一个客户将其部署为SAN交换机堆栈（使用3750X），其中SAN以10Gbit的速度连接，然后将他们的ESX主机以Gbit（或使用LAG的多个Gbit）连接，并且输出下降的数量是天文数字您如何尝试调整缓冲区。

同一客户在同一DC中为其他网络拥有另外两个3750堆栈，这些堆栈都是干净的。

TL; DR：这实际上取决于要通过堆栈的流量类型以及瓶颈所在的位置。

3560/3750内的电源/风扇不可热插拔/一旦安装了交换机，并且这些设备不可避免地发生故障，则在卸下3560/3750并将其更换为RMA时，必须将所有服务器从3560/3750上拔下。

此外，3560s / 3750s上的风扇方向也会成为热通道/冷通道以及其他冷却设置的问题。将交换机安装在交换机端口面向服务器背面的位置时，会导致交换机风扇朝错误方向吹动的情况。这会使开关过热，使其更有可能发生故障/需要更换。