在Internet边缘路由器上，eBGP与多个运营商通话，而iBGP与其他运营商通话，除了每个路由器上的一个串行全DS3（〜45Mbps）速率外，LAN和WAN侧的所有接口均为GE。尽管我认为我几乎没有在串行接口上​​发送太多流量（在3-10Mbps范围内），但我看到恒定的输出队列丢弃（OQD）。可能的解释是，由于负载间隔为30秒（最小值），并且SNMP轮询平均5分钟内的平均流量，因此我没有看到真正的突发流量？

平台是Cisco 7204VXR NPE-G2。 


Serial1/0 is up, line protocol is up
  Hardware is M2T-T3+ pa
  Description: -removed-
  Internet address is a.b.c.d/30
  MTU 4470 bytes, BW 44210 Kbit, DLY 200 usec,
     reliability 255/255, txload 5/255, rxload 1/255
  Encapsulation HDLC, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  Last input 00:00:02, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:35:19
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 36
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 260000 bits/sec, 208 packets/sec
  30 second output rate 939000 bits/sec, 288 packets/sec
     410638 packets input, 52410388 bytes, 0 no buffer
     Received 212 broadcasts, 0 runts, 0 giants, 0 throttles
              0 parity
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     515752 packets output, 139195019 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
   rxLOS inactive, rxLOF inactive, rxAIS inactive
   txAIS inactive, rxRAI inactive, txRAI inactive


24小时后将显示成千上万的OQD。我们确实在每天凌晨3点左右推出更多流量，所以也许这里有些突发流量我没有给予足够的重视。

Last clearing of "show interface" counters 1d01h
Input queue: 0/75/0/158 (size/max/drops/flushes); Total output drops: 12049


我想在DS3上发送更多的出站流量，但我对OQD并不担心。 DS3后面的第2层ISP的POP是与6层以上的第1层的对等点的两倍，因此，其想法是使客户端的网络流量尽快增长，而不是GE上第1层的GE主ISP ，但必须努力实现对等交换。入站流量不是问题。

在这种情况下是否有比fifo更好的排队策略？查看有关输入和输出队列丢弃的Cisco文档，不建议增加出站队列大小，因为数据包已经在路由器上，最好丢弃输入，以便TCP可以限制应用回退。我们的GE链路上有足够的带宽，因此实际上不需要限制输入。这些路由器上没有策略映射。 90％的出站流量来自我们的HTTP响应；其余大部分来自FTP和SMTP。 GE链接推动50-200 + Mbps。

您是否建议对输出队列大小缓冲区进行任何调整？这些串行接口是我们的备份链接，出于较早给出的原因（如果有效），我宁愿使用更多这些链接，但是我对自己的BGP策略进行了调整，这些策略试图不使该串行接口超载（在大多数情况下，其负载很低）。 br />

#1 楼

没错，在SNMP上不会真正看到突发性。 1GE可以发送1.48Mpps，因此拥塞45Mbps的时间非常少，而45Mbps可以处理不到75kpps。

如果您的入口是1GE，出口是45Mbps，那么显然45Mbps的拥塞点将需要丢弃数据包。这是正常现象，是预期的。如果增加缓冲区，则会引入更多延迟。
1GE需要0.45ms来发送40个1500B IP帧，现在这是您可以处理的突发量。但是，以45Mbps的速度将它们从队列中移出已经花费了10ms。

如果您没有任何严重的问题，我可能不会对此做任何事情。但是，如果某些流量比其他流量更适合丢弃，则应将FIFO替换为基于类的队列。假设您想确定优先级，以便删除更多的ftp和减少voip。 br />如果您想使用更深的缓冲区来碰碰运气，则应满足以下条件：

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT


这会在Serial1上造成50ms的缓冲区，并允许您从单个Gige接口处理高达2.25ms的突发信号。

评论

主要入口和出口是我们主要路径上的1GE，其中一定比例的流量通过DS3。编辑Q以显示出90％的出站是HTTP响应流量，其余部分由FTP和SMTP组成。

–generalnetworkerror
2013年6月1日9:21
由于缓冲导致的延迟，我将避免在Gige可用时使用DS3。所有这些提到的应用程序似乎都非常延迟并且可以容忍损失。

–ytti
2013年6月1日上午9:26
我之所以没有提到要使用更多DS3的另一个原因，是为了避免GE WAN链接上的突发费用> 100Mb。尽管我们每天都突破100Mb，但还不够长（到目前为止）。

–generalnetworkerror
2013年6月1日上午9:31
您可以通过引入更多延迟来为DS3吸引更多流量，甚至减少数据包丢失。但是，如果您打算提高流量速率，那么问题只会越来越严重。请记住，以太网永远不过是100％或0％，而是100％的长度会有所不同。因此，您最终将始终缓冲由高速1GE网络引起的突发。

–ytti
2013年6月1日上午9:34
我对200个数据包的理由是在45Mbps上发送数据包所需要的延迟，即50ms，这对于数据应用程序来说仍然可以忍受。您应该问自己，您将忍受多长时间的延迟，然后指定缓冲区以实现该目标。在您的情况下，我只会使用gige。

–ytti
2013年6月1日上午10:08

#2 楼

OQD通常是由以下两种原因之一引起的：


持续不断的高使用量或突发流量。
您已将策略映射应用于接口，该策略映射被配置为执行诸如监管或整形部分或全部流量之类的操作
在网络上存在某种错误界面，请查看错误计数器（show interface Serial1/0 counters errors）并检查其是否由于错误而不会丢弃数据包。

您可以研究一下（如果尚未获得）将策略映射放入可以执行以下操作：将关键任务流量分配给自己的队列，在常规流量（WRED）上避免拥塞，甚至只是对流量进行公平排队，以便在传输接口的流之间共享带宽。

正如您所提到的，另一种选择是增加接口上的输出队列大小，但是如果您要使用策略映射，则因为策略会创建其他子队列，所以还是不需要这样做。