为什么我们在带宽测量仙人掌图上会有很大的波动？

我们正在进行网络上以太通道和路由的冗余测试。在此干预期间，我们进行了一些测量。我们的监视工具是Cacti for graph。监视的设备是VSS上的4500-X。每个链接位于不同的物理机箱上。

架构：

测试年代：
[t0] te1 / 1/14端口上的链接已被物理删除。Te2 / 1/14已激活。Po1处于运行状态。
[t0 + 15] Te1 / 1/14端口上的链接已恢复正常工作，并检查是否
已物理移除te1 / 1/14端口上回到以太网通道Po1的端口[t0 + 20]链接。Te2 / 1/14已激活。Po1处于运行状态。
[t0 + 35] Te1 / 1/14端口上的链接恢复服务，并检查该端口是否回到以太通道Po1中

在我们的测试中，我们监控了通过仙人掌的交通以太通道Po1（下图），并注意到当禁用te1 / 1/14链接（链接te2 / 1/14资产）时，流量值发生了显着变化，而反向链接相当稳定。我们也检查了int Po1上的计数器，这些计数器保持相当稳定。

在配置了LACP的Etherchannel上捆绑了10G的两个接口。在etherchannel内，它们是2个VLAN。一个用于多播流量，另一个用于Internet /所有流量。

您知道这种行为的可能原因吗？

扩展ytti的评论。

您的轮询间隔似乎很小，如果我没看错的话，每10秒轮询一次。有几个原因可以得到该结果。

设备方面：

• 计数器选择不当，如果您使用32位计数器，则以线速运行10g接口时，它们可能每隔3.4秒滚动一次
• 计数器更新，许多较大的设备每分钟仅更新计数器两次或三次，因此永远不能依赖它们进行同步。每隔30秒就低到我需要打扰的时间，即使这样，在触发任何警报或采取措施之前，我总是希望至少有两点
• 可能会有些麻烦，因为与用于批处理不打算进行RE的数据包相比，可以立即计算发送给CPU处理的数据包（也许是网络流）（在Juniper MX上已经看到了）

轮询器端：

• 轮询程序是否在该时间间隔内准确轮询，如果不是，则将其结果注入实际的轮询时间（例如，yz秒中的x位），以便可以计算出合理的速率
• 当计数器重置或未响应SNMP GET时，会发生什么情况，不同的工具以不同的方式响应这些问题

您的问题就是这样，您的路由器采样和您自己的轮询不会同时发生。也就是说，即使轮询间隔是静态的，轮询间隔也包含不同数量的样本，您的数学未将其考虑在内。
考虑到您已经轮询了t1，t2，t3，但是路由器没有在t1，t2的间隔进行任何采样，因此t1，t3之间的所有流量最终都达到了t2，t3的轮询值。导致在t1，t2的速率为0，而在t2，t3的速率超过线速率

现在，我将提出一种解决方案，但是请与对数学有粗略了解的人进行验证。

首先找出您感兴趣的接口（如果是ge-1 / 1/1）：

snmpbulkwalk开关ifDescr | grep ge-1 / 1/1

然后，您将看到它的ifIndex号，假设它是'42'。

然后执行以下操作：

while true; do
  snmpbulkwalk SWITCH ifHCInOctets.42 >> DATA
  date >> DATA
  sleep 1
done

现在，分析结果以确定平均实际更新计数器的频率。（如果需要，我可以生成用于分析的脚本）

接下来是我们需要数学的部分，但是我会建议一个简单的解决方案。

如果您的更新间隔是10s，则每5s轮询一次，即更新一次。那么你的样品将是

t0，t5，t10，t15，t20，t25，t30

现在，这将是您不使用的原始数据，但您希望像这样从中恢复实际样本

s1 = (t0+t5+t10)/3
s2 = (t10+t15+t20)/3
s3 = (t20+t25+t30)/3

这里的理由是，我们希望跨界泄漏，以减少交换机上不正确的轮询间隔的影响。

然后，您将绘制s1，s2，s3的图，并且比现在看到的结果更平滑/准确。

但是，我确定这不是一个新问题，并且我确定有一个正式的解决方案可以恢复最佳精度，但不幸的是，产生这种解决方案超出了我的技能范围。math.stackexchange人员可以更好地应对。

由于您以与计数器更新相同的速率进行轮询，因此您可能不同步。

通过配置

snmp-server hc poll <<hundredths of a second>>

您可以将SNMP计数器的更新间隔缩短为1秒左右。当您每10秒轮询一次时，这将导致吞吐量的更准确的值。

仅供参考，这是一个隐藏的命令。