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

架构:



测试年代:
[t0]物理上删除了te1 / 1/14端口上的链接。 Te2 / 1/14已激活。 Po1可操作。
[t0 + 15] Te1 / 1/14端口上的链接恢复服务,并检查端口是否回到以太网通道Po1
[t0 + 20] te1 / 1/14端口上的链接已被物理移除。 Te2 / 1/14已激活。 Po1可以正常运行。通过Cacti(下图),并注意到当我们禁用te1 / 1/14链接(链接te2 / 1/14资产)时,流量值发生了显着变化,在反向过程中相当稳定。我们也检查了int Po1上的计数器,这些计数器保持相当稳定。在etherchannel内,它们是2个VLAN。一个用于多播流量,另一个用于Internet /所有流量。

您知道此行为的可能原因吗?

评论

您参加了多长时间的考试?

每个端口断开连接需要15分钟,如按时间顺序所见。

双方的端口通道配置和负载均衡类型是什么?您能告诉我们有关产生该流量的测试套件和参数的信息-一个流,多个流,协议等。

在配置了LACP的Etherchannel上捆绑了10G的两个接口。在etherchannel内,有2个VLAN。一个用于多播流量,另一个用于Internet /所有流量。问题已更新。

该测试是针对路由协议和以太通道的通才冗余测试。如果链接断开,会发生什么情况。所有测试均按预期运行,但我们想知道为什么这种对bandwitdh的测量行为。

#1 楼

延长ytti的评论。

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

设备方面:


计数器选择不多,如果您使用的是32位计数器,如果您以线速运行10g接口,则每隔约3.4秒滚动一次
计数器更新,许多大型设备每分钟仅更新计数器2到3次,因此永远不能依赖它们同步。每隔30秒就低到我需要打扰的时间,即使这样,在触发任何警报或采取措施之前,我总是要至少要加2点。 )可以立即算出来,而不是不进行RE批处理(已经在Juniper MX上看到过)

轮询器端:间隔,如果不是,则将其结果注入实际的轮询时间(例如,yz秒中的x位),这样就可以计算出合理的速率
计数器重置或不响应SNMP GET时会发生什么,不同的工具以不同的方式响应这些问题


评论


即使您非常精确地每N轮询一次,该框也可能不会以准确的间隔轮询HW计数器,这使得t1,t2似乎没有流量增加,t2,t3却看到线速过高。现在,您可以获得的最准确的结果可能是在math.stackexchange领域中,但我相信最好的方法是2 * the_slowest_update_interval,如果框每10s更新一次,则您可能每20s获得一次测量数据。但是可能有些统计魔术可以使它接近10s(这里的问题是更新间隔没有正确计时)

–ytti
13年6月4日在9:20

另外,与仙人掌一起使用的哪个轮询程序会在10秒的轮询间隔内起作用。在这些较低的轮询间隔内,我对默认轮询器的使用体验很差。如果他们使用Spine或默认轮询器,则不会提及。

–布雷特·莱金斯(Brett Lykins)
2013年6月4日10:39



#2 楼

您的问题就是这样,您的路由器采样和您自己的轮询不会同时发生。也就是说,即使轮询间隔是静态的,轮询间隔也包含不同数量的样本,您的数学计算并未考虑该样本。
考虑您已经对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


现在分析结果以确定平均实际更新计数器的频率。 (如果需要,我可以提供用于分析的脚本)

然后是我们需要数学的部分,但是我会建议一个简单的解决方案。

如果您进行更新间隔为10秒,每5秒轮询一次,即更新频率的两倍。那么您的样本将是

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人员可以更好地解决这些问题。

#3 楼

由于轮询的速率与计数器更新的速率相同,因此可能不同步。

通过配置

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


,您可以减少SNMP计数器的更新间隔大约为1秒。每隔10秒轮询一次,应该会获得更准确的吞吐量值。

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