有没有办法证明他们在DC部署中有多糟糕？我经常听到人们说他们尽快删除了3750，但是我还没有听到实际的故障情况，可以用来让管理层知道如何将其撤出。
#1 楼
FWIW我曾经在TOR设置中大规模使用过3750（3750G，然后是3750E / 3560E）。最初使用L2端口通道/ GLBP（2x1G和2x2G的变量以及用于数据库机架的罕见2x4G），然后使用L3的TOR（用于3750E / 3560E的内核和10G的内核）。我在说成千上万的。我们只看到了用于带宽最密集的服务的缓冲区问题，那时我们无论如何都在寻找10G到主机（以及带有24-48 SFP +的密集披萨盒）。能够向管理人员证明的一切实际上将取决于应用程序，您将根据设计和应用程序的要求来做作业，并确切了解应用程序的规格以及预期的增长速度。与您的管理链以及网络的主要所有者/客户一起进行设计审查。
管理层希望查看数据，如果您没有足够的资源来全面测试该设备，提出一个测试计划，将其连接到一些流量生成硬件，对其进行全面评估，并对它进行设计规范的压力测试等），这将很难做到。他们不会被轶事证据所打动，发现这种硬数据可能会很难，因为我敢肯定，出版这种东西的人会违反所有NDA。
对此发布答案的其他所有人都很好地概述了3750平台的“问题区域”：堆栈固有的堆叠模式和怪异的故障模式，缓冲区大小等。还有一个问题，概述了在输出队列丢弃上收集SNMP统计信息的问题。 -缓冲区在ASIC之间共享，因此对于特定的端口范围，通过SNMP获得的所有统计信息都将是相同的（这可能是您管理链遇到的一个棘手问题）。
总而言之，我想说3750/3560对于大多数部署来说都是“不错的”，即使规模较大。如果可以的话，请避免将它们堆叠在一起，但是我要说的是，以很小的数量和易于管理的数量这样做并不太可怕。
#2 楼
这实际上取决于您的部署方案。 3560 / 3750s是出色的交换机，具有不错的缓冲区，通常对于大多数应用程序都可以正常工作。如果数据中心看到需要更大缓冲区的流量，则应该能够从交换机提取统计信息，例如缓冲区使用率和数据包丢弃。说服管理人员丢弃正在丢弃其数据包的交换机，这并不是一个太大的挑战。我想。评论
“删除正在丢弃其数据包的交换机”-太好了！
– Stefan
13年5月27日在21:01
#3 楼
在3750的早期，尤其是2010年左右之前发布的堆叠技术，交换机故障存在很多问题，导致堆叠以不太优雅的方式失败。结合升级堆栈不是最直观的过程（此后一直在改进）这一事实，3750的声誉一直不佳，此后一直持续。在小型数据中心，3750堆栈代表了一种相对低成本的选择，无需使用基于机箱的交换机即可获得端口密度。我本人只是为一个较小的客户安装了一个数据中心解决方案，其中涉及一些带有Netapp FAS2240的Cisco UCS C220 M3服务器，并且我使用了3750的堆栈为每个新设备及其所有旧服务器提供多机箱以太网通道冗余。在过渡期间。它确实非常有效。
那么-3750是否有问题？可能与已经存在很长时间的任何其他交换机相同。 6500在其生命周期的早期就有问题，现在已经出了很多年了，还不错。我建议您查看将要投入的内容，如果性能指标保持不变，则请确保保持警惕。
评论
我也成功使用3750多次。再说一次，我的DC部署非常小，因为我大部分时间都花在MPLS核心上。我一直在听到它们有多“糟糕”，并且我确定它们在某些方面不利，但是从未见过这些陈述得到了硬数据的支持
–柔和
13年5月27日在22:20
同样，我认为这主要是产品的历史问题。更不用说您应该将它们部署到任何地方，基于机箱的端口要求更高，成本效益更高-更不用说3750缺乏下游10GbE功能。在我看来，这是一个相当标准的规模调整问题产品已经消除了一些大皱纹。
–默丁
13年5月27日在22:31
#4 楼
老实说，我看到3750受到抑制的最常见方法是将核心交换机升级到Nexus 7k。通常（但并非总是），刷新的一部分是将TOR移至Nexus 2000 FEX或Nexus 5000s。即使3750的缓冲区没有最大，在大多数人的脑海中，它们也可以正常工作在大多数企业DC环境中都足够好。
除非您可以为在DC中安装3560/3750所引起的问题投入一美元的价值，否则我怀疑您是否能够说服管理层更换它们在常规产品刷新周期之外。
评论
从它们那里我听到的最大问题是，当您可能有几台服务器连接到演出接口，并且连接到WAN的接口不超过100Mb时。但是再次，我还没有看到硬数据来支持这一点
–柔和
13年5月27日在22:22
对于小型缓冲区，这将是一个问题，因为您将从备份的演出链接中备份数据以等待命中100Meg链接，但这不是缓冲区问题-这是“我们没有调整WAN的带宽大小”正确”的问题。
–巨石
13年5月28日在0:47
#5 楼
@mellowd当然是正确的，这些开关不是非常有用的DC开关，因为它们的缓冲区非常有限，它们会微爆发并丢弃流量。请考虑您有2 * 1GE入口和1 * 1GE出口。最糟糕的情况是，出口端口同时发送2ms后，出口端口开始下降。
最好的情况是，您可以处理8ms的突发信号。
您有2MB每4个端口的出口缓冲区数，因此2MB /（1Gbps / 8）=最多16ms，最小16/4 = 4ms。
将该数字除以要发送的入口端口的数量，即可得到多长时间您可以处理它。
也就是说，添加的入口端口（服务器）越多，处理的微脉冲就越少。
如果必须与3750/3560一起使用，则应阅读以下内容文档以最大程度地使用缓冲区。而且，即使您的图表显示平均出口需求非常低，即使您仍要在出口上使用LACP，也是如此。
向管理人员证明缓冲区不足，无法监控/挖掘/跨越当前网络将交换所有下行链路，然后您将拥有时间戳和要发送的数据包大小，并且可以计算瞬时需求超过1Gbps的数量以及需要处理多少缓冲区。
#6 楼
性能当然是一个重要的问题，并且上面已经很好地解决了，但是基于功能和功能集还存在很多差异：在许多情况下，对外部RPS单元的需求是一个巨大的问题安装– 1U交换机在初始成本，空间损失和持续管理方面变得更加昂贵。在最小的数据中心环境中，冗余电源应被视为绝对必需。
大量和大量不必要的代码正在运行，以实现最终用户连接–出现缺陷，安全问题和停机的机会更大。
DC功能（ISSU，DCB，存储，某些内置脚本元素）不在（也不会在）以校园为中心的设备上。 DC产品之外的当前状态和路线图也往往缺少以合理的方式管理和扩展L2扩展的机制（即FabricPath / TRILL，OTV，VXLAN等）。这里的列表只会增长–现成的虚拟化，硬件辅助机制的支持等。
可扩展性–您如何发展基础架构？大量的开关（管理昂贵）？堆叠（操作困难，主要的布线问题）是一团糟。此外，在密度方面，接口类型（例如，光纤与铜）的灵活性可能具有挑战性。
一般来说，DC和壁橱切换之间的差异在不断增长。在思科世界中，出于非常充分的理由，存在不同的操作系统（NXOS与IOS）–千差万别的要求产生了不同的解决方案。数据中心不需要用户身份验证机制（802.1x）或功能强大的AV集成的功能速度，而布线室则不需要终止大量10GE的功能。用于不同工作的不同工具。连接台式机的Nexus盒也不太理想。
我还将向您指出各种设计指南（CVD等），它们为在网络中各个点使用的交换机类型提供了基本原理。对于通常类似于行业最佳实践的解决方案，有话要说，而您提到的交换机通常不在DC中占有一席之地-除了管理网络或某些特殊情况下的本地连接情况。
#7 楼
我有一个客户将其部署为SAN交换机堆栈（使用3750X），其中SAN以10Gbit的速度连接，然后将他们的ESX主机以Gbit（或使用LAG的多个Gbit）连接，并且输出下降的数量是天文数字同一客户在同一DC中为其他网络有另外两个3750堆栈，这些堆栈都是干净的。
; DR：DR确实取决于要通过堆栈的流量类型以及瓶颈所在的位置。
#8 楼
3560/3750内的电源/风扇不可热插拔/一旦安装了交换机，并且这些设备不可避免地发生故障，则在卸下3560/3750并将其更换为RMA时，必须将所有服务器从3560/3750上拔下。3560s / 3750s上的风扇方向也成为热通道/冷通道和其他冷却设置的问题。将交换机安装在交换机端口面向服务器背面的位置时，会导致交换机风扇朝错误方向吹动的情况。这会使开关过热，使其更有可能发生故障/需要更换。
评论
首先通过收集性能数据证明它们是一个坏主意。假设您的管理人员从一开始就准备好，并且会听取性能数据参数。许多可怜的网络灵魂被CTO所征服，他们对技术的了解不如他们所想的那样，宁愿将钱花在高度可见的项目上，也不愿隐藏一些看不见的网络基础设施。另一方面，拥有CTO可以听取推理并不意味着使用性能更高的开关，因为需要理解并证明应用程序的性能要求以支持当前和预期的增长。
除非您的核心Nexus需要3560以外的功能，否则我认为3560/3750交换机是很棒的。面对现实，这些天谁有1万美元可用于1U交换机？除非您做一些特别的事情，否则答案将是没人。