g0pher：回复@H3C技术:你仔细看图2；多个S1同时送到某个S2上的cell会Congested, 你只能用S2上的Buffer或S2-->S3加速来解决；但是也不能完全解决(动态流量原因)。"严格“无阻塞这个说法是错误的。有本书不错－http://t.cn/aFA6aW

解答如下：

这个问题如果只针对S2一级来看，是存在问题。特别地，如果这不是设备内部架构，而是网络架构的话，问题还很大。

如果是网络级问题，就是下图表示的一个组网结构。

网络S1,3为接入，S2为Fabric，要求接入S1,3交换机以round robin方式将负载上送到S2，网络中数据流报文大小全部是1.5KBytes，报文乱序问题由应用解决，网络只负责“无阻塞”转发。

这样一个具有多种约束条件下的组网，是一个接近完善的CLOS架构，但还是比较适合这个问题，多个S1,3数据流到达S2的时候确实会产生拥塞（其实round robin下拥塞的概率也是很小的，只有HASH方式时拥塞一测一个准），从而引起整个网络不能完全无阻塞。

再回到设备级来讨论问题。当然不同的设备实现不一样，我们以12500的实现为例来讨论，交换是S1、S2、S3的多级，当然S2本身肯定是高加速的，实际上每个线卡的线速端口数是8个（很快会翻一倍），但是只占到内部S1-S2、S2-S3带宽的60%，并且也是如这位网友所说，S2上必然有一定buffer，CELL交换也是需要存储空间的。

这些是很多corssbar经典架构也都一样的（包括VOQ，原来我们的9500就支持VOQ），那么还有什么区别呢？有3点：Ingress大buffer，切片等长以round robin方式上Fabric，Egress通过Credit来调度（即“拉”式转发模型）。前两点好说，严格无阻塞更重要的是依赖第三点，即通过Credit来控制Ingress的数据进入S2这一级，这个应该好理解。

这位网友所说的S2一级的拥塞是怎么产生的呢？具体分析如下

假定每个线卡芯片有4个万兆，则各芯片上行S2级Fabric总净带宽至少大于40G，分担到上图中S2每个Fabric带宽至少大于10G。因此就有以下结论：

芯片A1总Ingress流量的四分之一被分配到Fabric A2，记为0.25*A1（切片和round robin的功能会使这个分配很均匀，这里记Ingress=Egress是线速，而任意的Ingress=Egress则是无阻塞，同时记每个芯片的Ingress流量由芯片编号来代替即A1、B1、C1、D1）；

芯片B1有0.25*B1分配到B2；

……以此类推

现在说A2的Egress方向某个内部链路（应该是若干SERDES）发生拥塞，如上图红圈标记部分。拥塞的条件是S2多打一，实际上应该是S1的A1、B1、C1、D1（正常来说也还有S3这边的，简单起见就不算了，因为算上的话，从转发的角度都归到S1了）各自上到A2的4个端口收敛到一个端口，是收敛，就必然存在拥塞，但这里的情况有点变化了。A1、B1、C1、D1所有上行带宽中只有四分之一的流量到达A2，即0.25*( A1+B1+C1+D1)。

再来说流量，每个芯片40G单向能力，那么Ingress方向40G流量任意分配到A1、B1、C1、D1，然后能够到达A3出去，要求这40G的吞吐流量不发生丢失减损。（从严格CLOS/无阻塞角度上，应该是分析所有芯片都有40G的Egress流量，由于12500体系架构的对称性，我们只分析其中一个芯片A3的Egress，并且假定是一个40G端口，如果按照10G端口来看，则只需要分析每个10G端口的Egress流量，本质等同）。

实际上就是40Gbps= A1+B1+C1+D1，上到A2的流量就只有10Gbps了，而A2画红圈的链路最小带宽必然大于10G（加速和缓存是必然存在的），加上A1、B1、C1、D1的切片和round robin带来数据转发的均匀性，因此极大降低了拥塞。

以上是就硬件连接本质而言，很多设备的架构甚至组网也是逐步接近这种效果（比如有些组网里增加S2平面的设备数，就是为了增加加速比和buffer能力）。

另一点加强的就是Credit机制了，这个和VOQ是配合用的，不过这里不讲VOQ（搞网络的人都知道VOQ的好处），我们只讲12500的“拉”模式转发。忽略掉S2平面，只看S1之间的调度，在每个芯片后都有个调度器TM（Traffic manager），出口FA会定时向入口方向的调度器发送各VOQ发送队列的属性及空满状态。每个队列根据从调度器收到的累计Credit数量给交换网发送相应流量的报文，并根据实际发送量递减剩余的Credit数量。因此，只要出口有资源，入口就会根据Credit情况发送数据流，如果出口Credit资源不够（设备的Egress端口发生瞬时拥塞），Ingress就降低发送速率或停止相应VOQ的数据发送，而此时Egress出端口依然保证线速的数据转发，只有释放了的Credit资源（部分）通告给Ingress芯片TM，在瞬时拥塞期间，所有Ingress的流量会缓存在Ingress芯片外挂的大buffer中，当然，长时拥塞（不对称的带宽比造成的），那就是网络流量的拥塞了，与架构无关了。

12500的这种Credit机制，我们也称为内部的lossless方式，即不会发生内部的丢包，只在Ingress丢包那是buffer溢出了，或者就是网络流量模型是拥塞、流量路径持续收敛而造成的。

实际上，CLOS、严格CLOS，或称无阻塞、完全无阻塞，也都是比较相对的概念，只是强调产品的架构适应能力有差异而已，无需在概念上过于区分。

PS：

有些设备的Ingress芯片上Fabric是通过路径指定或HASH做的，而且还没有内部的E2E调度机制、VOQ机制，要想做到完全无阻塞/严格CLOS，还是有难度的。

更有说服力的不是这些文字游戏，而是客户环境的验证与测试，所以我们欢迎任何对H 3C产品感兴趣的人士来对我们的设备进行性能测试，乃至对比测试，希望通过实际数据满足关注H3C人士的需求，我们已经经过了国内外太多的严格测试，有不足，更有改进和优化。

那本书，简单看了一些前面的内容，理论的东西很多，真正实现的时候，受限制条件比较多，因为涉及很多芯片的配合、设计与加工工艺水平等，就如同2000年我们引入《the switch》一书到国内，当时大家作为圭臬研究，但随着芯片技术的发展，更新的技术不断替代了。我们后续会继续研究，相信H3C有更高端更好的产品展现给大家。