我们已经租用了几条租用的线路，这些线路将自己呈现为第2层网络，即您在数据中心有一条大管道，而远程站点的管道则较小。在第2层网络中，您可以执行任何操作。他们可能使用802.1ad为每个客户在其网络内提供各自的网络。 AFAICS大多数站点通过纯VDSL连接。
我们决定在每个站点放置一个路由器，并为每个站点分配自己的VLAN。因此，DC上的防火墙定义的VLAN与站点的数量一样多。因此，每个站点都在其自己的VLAN中使用其on地址范围。
网络图： >现在，我们面临吞吐量问题：
运行从站点到DC的FTP传输在大约10Mb / s的线速下可以正常工作。
运行FTP传输从DC到站点的速度在6Mb / s或更低的速度下无法正常工作。唯一一致的事情是，一个方向行之有效。太糟糕了，这是通往站点的方向，因为这是我们最需要的带宽，因为我们想使用终端服务器客户端。
传输大约10秒钟后，吞吐量下降了。嗅探时我们会看到DUP ACK。这可能导致我在提供商端限制速率？ （当前，它们没有任何线索，我想确保在升级之前我们没有错）
注意远程站点以某种方式限制为10Mb。将“切换到都会”端口设置为10Mb也不起作用。实际上，这是最糟糕的情况（最大30 KB / s）。设置为100Mb可以正常工作，但已经开始产生上述问题。与1G相同。
可以在此处下载问题的摘要：您会看到带有一些错误详细信息的Wireshark IO图：
在左侧：FTP从DC到站点的传输
右侧：从站点到DC的FTP传输
如果另一端启动了传输（即从dc放置，而不是从远程获取），则问题出在保持不变。
请沉迷于您所认为的问题所在。 >
UPDATE＃2（已更新）
这必须是一个拥塞控制对象。
请注意，从DC到远程，我们有10G-> 1G-> 100M -> 10M-> 1G链接。 <-不起作用
从另一个方面来说，我们得到相反的结果：1G-> 10M-> 100M-> 1G-> 10G。 <-很好
第一个“ 1G-> 10M”是远程站点上的“不可见” 10M，其中包括上行链路端口速度在内的所有内容都设置为1G，即使仅落后10M
但是DC上的100Mbps是真实的100Mbps，但是在物理层上该接口配置为100Mbps。 />
TCP测试只能在一个方向上正常工作（客户端= DC，服务器=远程）
* http://178.63.11.6/dc-to-remote_dc-side.pcapng
* http://178.63.11.6/dc-to-remote_remote-side.pcapng
深入了解一下，这是来自同一VLAN中两台主机但仍使用城域连接的UDP测试，200 =远程，201 = DC
带宽（接近10Mbps时，我们有0.93％，这很关键...并且还会解释TCP为什么执行有问题）问题仍然存在：
我们并没有超额订购DC链路，因为DC链路的速度为100Mbps，并且发送的速度不能超过100Mbps。但是，远程站点的速度为10Mbps。
远端的缓冲区是否溢出并丢弃数据包？
提供商的流量整形器是否对流量进行了处理？ （来自另一个节点的流量会受到ISP流量整形器的影响还是会受到（从外部）进入该节点的流量的影响？）……您明白我的意思吗？
TCP为什么不能独自处理所有这些？
更新＃3
我现在使用以下情况：
./iperf -c 192.168.x -i2 -t 60 -r ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 192.168.x, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.x port 38195 connected with 192.168.x port 5001 [ 3] 0.0- 2.0 sec 1.44 MBytes 6.03 Mbits/sec [ 3] 2.0- 4.0 sec 2.23 MBytes 9.37 Mbits/sec [ 3] 4.0- 6.0 sec 2.28 MBytes 9.57 Mbits/sec [ 3] 6.0- 8.0 sec 1.88 MBytes 7.90 Mbits/sec [ 3] 8.0-10.0 sec 1.00 MBytes 4.19 Mbits/sec [ 3] 10.0-12.0 sec 1.30 MBytes 5.47 Mbits/sec [ 3] 12.0-14.0 sec 688 KBytes 2.82 Mbits/sec [ 3] 14.0-16.0 sec 840 KBytes 3.44 Mbits/sec [ 3] 16.0-18.0 sec 1.03 MBytes 4.33 Mbits/sec [ 3] 18.0-20.0 sec 1.01 MBytes 4.23 Mbits/sec [ 3] 20.0-22.0 sec 1.03 MBytes 4.33 Mbits/sec [ 3] 22.0-24.0 sec 1.18 MBytes 4.95 Mbits/sec [ 3] 24.0-26.0 sec 904 KBytes 3.70 Mbits/sec [ 3] 26.0-28.0 sec 840 KBytes 3.44 Mbits/sec [ 3] 28.0-30.0 sec 936 KBytes 3.83 Mbits/sec [ 3] 30.0-32.0 sec 1.09 MBytes 4.59 Mbits/sec [ 3] 32.0-34.0 sec 960 KBytes 3.93 Mbits/sec [ 3] 34.0-36.0 sec 752 KBytes 3.08 Mbits/sec [ 3] 36.0-38.0 sec 1.09 MBytes 4.59 Mbits/sec [ 3] 38.0-40.0 sec 1.09 MBytes 4.59 Mbits/sec [ 3] 40.0-42.0 sec 840 KBytes 3.44 Mbits/sec [ 3] 42.0-44.0 sec 1.27 MBytes 5.34 Mbits/sec [ 3] 44.0-46.0 sec 1.16 MBytes 4.85 Mbits/sec [ 3] 46.0-48.0 sec 840 KBytes 3.44 Mbits/sec [ 3] 48.0-50.0 sec 960 KBytes 3.93 Mbits/sec [ 3] 50.0-52.0 sec 1.28 MBytes 5.37 Mbits/sec [ 3] 52.0-54.0 sec 1.09 MBytes 4.59 Mbits/sec [ 3] 54.0-56.0 sec 992 KBytes 4.06 Mbits/sec [ 3] 56.0-58.0 sec 1.00 MBytes 4.19 Mbits/sec [ 3] 58.0-60.0 sec 1.09 MBytes 4.59 Mbits/sec [ 3] 0.0-60.2 sec 33.9 MBytes 4.73 Mbits/sec [ 5] local 10.x port 5001 connected with 192.168.x port 10965 [ 5] 0.0- 2.0 sec 1.85 MBytes 7.75 Mbits/sec [ 5] 2.0- 4.0 sec 1.90 MBytes 7.98 Mbits/sec [ 5] 4.0- 6.0 sec 1.89 MBytes 7.93 Mbits/sec [ 5] 6.0- 8.0 sec 1.92 MBytes 8.07 Mbits/sec [ 5] 8.0-10.0 sec 1.91 MBytes 8.02 Mbits/sec [ 5] 10.0-12.0 sec 1.83 MBytes 7.69 Mbits/sec [ 5] 12.0-14.0 sec 1.86 MBytes 7.78 Mbits/sec [ 5] 14.0-16.0 sec 1.79 MBytes 7.52 Mbits/sec [ 5] 16.0-18.0 sec 1.79 MBytes 7.52 Mbits/sec [ 5] 18.0-20.0 sec 1.89 MBytes 7.91 Mbits/sec [ 5] 20.0-22.0 sec 1.91 MBytes 8.00 Mbits/sec [ 5] 22.0-24.0 sec 1.88 MBytes 7.91 Mbits/sec [ 5] 24.0-26.0 sec 1.95 MBytes 8.16 Mbits/sec [ 5] 26.0-28.0 sec 1.90 MBytes 7.99 Mbits/sec [ 5] 28.0-30.0 sec 1.87 MBytes 7.84 Mbits/sec [ 5] 30.0-32.0 sec 1.85 MBytes 7.77 Mbits/sec [ 5] 32.0-34.0 sec 1.55 MBytes 6.49 Mbits/sec [ 5] 34.0-36.0 sec 1.92 MBytes 8.07 Mbits/sec [ 5] 36.0-38.0 sec 1.90 MBytes 7.99 Mbits/sec [ 5] 38.0-40.0 sec 1.84 MBytes 7.73 Mbits/sec [ 5] 40.0-42.0 sec 1.66 MBytes 6.95 Mbits/sec [ 5] 42.0-44.0 sec 1.92 MBytes 8.07 Mbits/sec [ 5] 44.0-46.0 sec 1.91 MBytes 7.99 Mbits/sec [ 5] 46.0-48.0 sec 1.90 MBytes 7.98 Mbits/sec [ 5] 48.0-50.0 sec 1.84 MBytes 7.70 Mbits/sec [ 5] 50.0-52.0 sec 1.93 MBytes 8.09 Mbits/sec [ 5] 52.0-54.0 sec 1.80 MBytes 7.54 Mbits/sec [ 5] 54.0-56.0 sec 1.83 MBytes 7.67 Mbits/sec [ 5] 56.0-58.0 sec 1.88 MBytes 7.86 Mbits/sec [ 5] 58.0-60.0 sec 1.85 MBytes 7.78 Mbits/sec [ 5] 0.0-60.3 sec 56.0 MBytes 7.79 Mbits/sec
这是DC->远程方向：（iperf 9 Mbps UDP测试）但是，在运行TCP测试时，remote-> DC方向的性能并不会比DC-> remote方向（大约5Mbps）好很多……。
我不确定我们到达了底部。
#1 楼
参考我们的Stack Exchange聊天...短篇小说，您需要控制城域以太网链路两侧的速度不匹配...为了清楚起见，我重新绘制了图表...注意1
DC（以绿色显示）从10GE到100M的转换非常快...这是100倍的速度转换，您通常需要实现某种形式的qos（例如整形）来减轻这种巨大的转变。请参阅此答案的底部，以获取DC需要整形的信息（每个站点）...
远端从1GE到10M CIR的转换非常快...这又是100倍的速度转换。通常需要整形或其他qos解决方法。
DC UNI（100M）和远程UNI（10M）之间似乎还存在速度不匹配；仅供参考，如果您的提供商实现了符合MEF的服务，它们并没有在整形，而是在监管。 TCP流量在整形时趋于表现更好。
对您自己的QoS的需求
您似乎对qos的需求提出了疑问，因此我将引用MEF的“了解运营商以太网吞吐量”白皮书，第9页...通过回顾，MEF白皮书的图2中的客户比您有更好的情况...他们购买了50Mbps CIR，但是其UNI是在1GE上交付的...您的远程站点在1GE UNI上具有10Mbps CIR。
The transition from legacy services such as T1, T3, Frame Relay and ATM
to Carrier Ethernet has created some unintended consequences. Not all customers have
conforming equipment facing the network which properly limits/shapes the traffic outbound
to the network, with deleterious results. For instance, on the 1 GigE interface of
Figure 2, if the customer’s equipment accidentally transmits long bursts of data at
150 Mbits instead of the SLA’s Committed Information Rate of 50 Mbits, 67% of the data
may be lost and network breakdown will likely result.
在编辑中响应其他TCP问题...
我们并没有超额订购DC链路，因为它的速度为100Mbps，并且不能发送超过100Mbps的数据...
我不同意，您可以在以下位置发送微脉冲10GE，因为您的DC具有10GE链路，但是Metro UNI为100Mbps。一个悬而未决的问题是，当您从10GE过渡到100M时，Enterasys LAN交换机（交换机A）上有多少缓冲。自己？
TCP会在看到数据包丢失时放慢速度来处理问题……它确实会因严重的数据包丢失而放慢速度（并可能中止连接）。因此，TCP正在做应做的事情……作为网络工程师，您的目标是建立一个使TCP感到满意的条件的网络。
聊天中的其他TCP问题
Marki说：我不明白在什么地方，由谁以及为什么以及为什么丢弃的内容，TCP不能简单地处理一个事实，即一端只有100Mb，对方则为10Mbps。
关于TCP的缓冲需求以及无缓冲的后果：
事实1：TCP需要缓冲以进行速度转换，因为它是设计为反馈控制系统。
使用驾驶类比：作为好的驾驶员，我们总是在我们和前方的汽车之间留有几秒钟的空间；在某些方面，汽车之间的空间大致类似于网络缓冲区。如果有动物在前面踩刹车时，我们前面的人猛踩刹车，我们的车子之间的空间（希望如此）可以防止我们撞到他们的车。我们之所以要留出空间，是因为我们的眼睛需要时间才能看到刹车灯，脚要做出反应，刹车要散发出足够的热量。我们的眼睛为我们提供了视觉反馈控制系统。
同样，当FTP会话以10GE爆发时，由于TCP缩放了窗口大小，在套接字必须停止并等待TCP ACK之前，突发流量可能长达4MB（在您的情况下）。同时，如果10GE流量突然达到“快速以太网”，则TCP需要逐渐降低速度。网络设备中的深层缓冲区允许TCP在进行速度转换时丢弃的数据包大大减少。但是，如果没有缓冲区，则当该4MB TCP窗口从10GE限制为100M时，可能会丢弃该窗口的99％。可以将那99％的严重损失视为TCP套接字崩溃； TCP可预测地对相对逐渐的数据包丢失做出反应。 TCP对正在发生的严重数据包丢失的反应要少得多。注3。关于为什么不应该使用DC为100M，远程为10M的非对称城域以太网CIR的问题，请询问您自己是一个反问：“谁在缓冲城域网提供商为您提供的便宜的10Mbps以太网NID时缓冲100Mbps的流量突然爆发？”（提示：没有人在缓冲）。没有人在缓冲较大的速度转换（请参阅注2），那么这些点是间歇性减少流量的潜在位置。 >
当TCP流量离开数据中心时，可以将其丢弃在三个位置：
在D1：因为LAN交换机很少有足够深的缓冲来支持100：1速度转换
在D2：如果NID以比CIR更高的速度协商UNI链路；
在D3：出于所有原因，我刚刚描述了非对称城域以太网CIR。
当TCP流量进入数据中心...
在D4：因为您有一个1GE UNI和一个10M CIR；这是我上面提到的D2的病理情况。
如何减轻速度不匹配：
EVPL解决方案示例：
在这样的交换拓扑中，从DC到每个Remote的点对点EVC的EVPL可能是最好的选择（请参见上图）。这会将单独的CIR应用于每个EVC。注意：此答案中的所有其他QoS指导均适用...即避免进行大的速度转换注2，而无需测试您的设备是否能够很好地应对这种情况。或者，您可以考虑购买在DC和DC之间具有对称速率的Metroe服务。遥控器;尽管我认为这可能不是最实用的指导。
FYI，针对路由服务此问题的经典解决方案是购买支持以所需速度进行整形的路由器，然后将选路流量整形为适当的CIR（每个远程站点）。仅供参考，远程端可以使用相当小的路由器，因为它只有1GE输入和10Mbps CIR。...几个月前，当我们谈论此服务的设计时，我建议路由，如果您对技术感到满意的话...
如果您没有多余的钱可花，又无法重新设计城域以太网服务，则可以逐步解决速度不匹配的问题。我从未做过，但是原则上您可以尝试将速度转换为10到1，而不是100到1（这是DC和远程设备当前的速度）： br />您可以尝试强迫远程UNI以100M（而不是1GE）的价格进行自动协商，而不是购买将路由器塑造为10M的路由器。 GigabitEthernet需要Cat5e电缆中的所有引脚，因此您可以使用仅连接引脚1、2、3和6的RJ45 Mod-plug有效地将其强制为100M。
无需购买路由器即可将DC整形为100M ，在向100M链接发送流量时，请使用Enterasys来监控10GE链接到1GE的链接。
分析
iperf结果...关于iperf（基于iperf版本2的所有信息），有两个要记住的要点：iperf测量TCP或UDP净荷带宽。换句话说，它忽略了TCP，UDP，IP和以太网标头的开销。由于您具有以太网服务，因此请记住相应地修改iperf结果。iperf客户端在测试过程中会将数据发送到服务器。因此，以下输出显示了DC计算机（在
iperf -c模式）连接到远程站点（192.168.x）上的iperf服务器，并将数据从DC（100M UNI）推送到远程站点（10M UNI）... ./iperf -c 192.168.x -i2 -t 60 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.x, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.x port 38195 connected with 192.168.x port 5001
[ 3] 0.0- 2.0 sec 1.44 MBytes 6.03 Mbits/sec
[ 3] 2.0- 4.0 sec 2.23 MBytes 9.37 Mbits/sec
[ 3] 4.0- 6.0 sec 2.28 MBytes 9.57 Mbits/sec
[ 3] 6.0- 8.0 sec 1.88 MBytes 7.90 Mbits/sec
[ 3] 8.0-10.0 sec 1.00 MBytes 4.19 Mbits/sec
[ 3] 10.0-12.0 sec 1.30 MBytes 5.47 Mbits/sec
[ 3] 12.0-14.0 sec 688 KBytes 2.82 Mbits/sec
上面的输出清楚地显示了直流到远程方向的问题；如果一切正常，我们应该期望看到9Mbps或更高的速度（即，您期望至少90％的容量-远程站点为10Mbps）。现在，让我们看一下相反的流量（当
iperf将数据从远程站点推送到DC时）... [ 5] local 10.x port 5001 connected with 192.168.x port 10965
[ 5] 0.0- 2.0 sec 1.85 MBytes 7.75 Mbits/sec
[ 5] 2.0- 4.0 sec 1.90 MBytes 7.98 Mbits/sec
[ 5] 4.0- 6.0 sec 1.89 MBytes 7.93 Mbits/sec
[ 5] 6.0- 8.0 sec 1.92 MBytes 8.07 Mbits/sec
[ 5] 8.0-10.0 sec 1.91 MBytes 8.02 Mbits/sec
[ 5] 10.0-12.0 sec 1.83 MBytes 7.69 Mbits/sec
[ 5] 12.0-14.0 sec 1.86 MBytes 7.78 Mbits/sec
您可以发送远程CIR容量的80％，但仍然比我的预期要少。
直流速度不匹配（10Gbps-> 100Mbps）的插图
说：别忘了，问题仅在流量为100Mb-> 10Mb时才会显示，而不是相反。
问题在双向显示，但是
iperf在DC->远程方向上症状似乎更严重。请参阅我对上面iperf输出的分析。要具体说明，我们将DC DC服务器（130.1.6.4）中的文件推送到远程站点（192.168.191.2）时，请查看FTP pcap ）。在传输过程中，从100M城域以太网侧进行的传输受到限制。如果查看
dc-to-remote_remote-side.pcapng pcap，然后对expert.message contains "segment not captured"进行过滤，就可以看到此内容。/>注1：我选择每1Mbps MetroEthernet CIR 25KB的CBS值；这是提供商使用的常见比率。YMMV注2我的个人规则：“大”是一个比10：1的速度转换大得多的速度转换。注3我不能给出关于什么是和不是的硬数字。 TCP的数据包丢失过多。如果损失严重到足以使您的应用程序遭受损失，那么它就太多了。我的个人规则：当完全在我自己的控制下处理有线公司网络时，任何（无意的）数据包丢失都太多了。就是说，有一些交换机模型可以在缓冲方面有所作为。这些交换机有时可能会丢包……这是对您是否必须忍受问题还是购买更好的交换机的判断。仅供参考：并不总是很明显，但是TCP会定期增加套接字的传输速率，以确保它获得尽可能多的吞吐量。许多TCP实现都知道当看到数据包丢失时它们会过快。
评论
请注意，DC的PHY速度（Metro以太网端口）已经达到100Mb。但是我也不能发送100M的数据，因为另一边最大为10Mb。哦，您的意思是“在DC->远程方向上，iperf症状似乎更严重”吗？
– Marki
2014年8月5日在11:51
我更新了答案，是的，“远程-> DC”是原始答案中的错字。
–迈克·彭宁顿
2014年8月6日上午11:35
我在这里与Mike保持一致，具体取决于您的提供商，如果您问他们，他们会告诉您终端的线路速率，请使其与挂在Metro-E上的物理接口相匹配。至于从WHERE到QoS，我会在您最大的切入点（即您的10Gb设备）上进行操作，然后再使用较小的上游设备。尽管我花更多的时间在防火墙和路由上而不是交换，但是希望迈克可以证实我的观点！
– A L
2014年8月6日15:02
@MikePennington-由于速度不匹配而导致的出口阻塞是我在P2P微波链接中经常遇到的问题。很好的答案，您的帖子中有很多很好的信息。谢谢！
–matak
2014年8月6日15:38
还要检查双工不匹配，这可能会导致单向速度问题。
– cpt_fink
2014年10月3日在7:45
评论
并不是一个真正的答案，但我的建议是获得一个JDSU并测试该电路。如果他们在监管您，请确保您获得策略程序，“调节器”，设置...如果他们的CBS很小，那么它们会将TCP流量限制在实质上较小的窗口大小。您可以通过后退2后退测试对此进行测试。我花了很多时间与L2电路的提供者进行反复交流，以了解当我们进行新的电路测试时，不仅要在CIR上，而且要在CBS上进行彻底的测试。另外，请注意。从Windows OS到Linux，TCP吞吐量将有所不同，因为TCP设置将有所不同。即。缓冲区大小，算法等。您可以通过sysctl来查看Linux机器的设置，不确定关于Windows ...也许是netsh。如果我要猜测您的电路出了什么问题，我会说，在分支站点的CPE设置的CBS比集线器端大……通常是相反的。同样，JDSU会将球打向他们，或者让您重新关注问题所在。
@matak为什么不对您的发言作其他回答？当我们谈论成形器时，我在哪里可以想象到该设备？ DC处有一个RJ45插头，没有（可见）CPE。在远程站点，我主要有一个VDSL调制解调器和某种支持MPLS的路由器。不确定他们是否使用MPLS。而且，整形器会向哪个方向行驶？我们可以对ingress @ spoke（来自站点），egress @ spoke（面向ISP的云），ingress @ hub（来自DC的），egress @ hub（面向ISP的云）进行整形……我可能错过了大局。您能说明为什么CBS的问题会成为问题吗？