什么是衡量 Cisco 路由器负载的指标

网络工程 思科 ios-xe 交通工程
2021-07-23 22:23:52

我设置了 Cisco CSR 1000v 路由器。我在 2 个路由器之间建立了 GRE 隧道,其中隧道的源是 GigabitEthernet1 接口。

我的目标是测量该 GRE 隧道上的负载。负载值可以计算如下:

Load (%) = Traffic (bps) / bandwidth or capacity (bps)

哪里Traffic(bps)是发送的流量量,bandwidth or capacity (bps)是隧道的容量。

从字面上看,该信息可以从路由器获得,但我很困惑在这种计算中必须使用哪一个。

GRE tunnel得到了下面的配置,我知道我要送这是交通量100Mbps

interface Tunnel0
 bandwidth 256
 ip address 10.10.1.1 255.255.255.252
 load-interval 30
 ....
 ....
!

如上所示计算负载是否正确?

我还从 CLI 找到了有关界面的以下信息csr1000v#sh interfaces gigabitEthernet1

csr1000v#show interfaces  gigabitEthernet 1
GigabitEthernet1 is up, line protocol is up 
...
  reliability 255/255, txload 3/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full Duplex, 1000Mbps, link type is auto, media type is Virtual
  output flow-control is unsupported, input flow-control is unsupported
  ...
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 1000 bits/sec, 3 packets/sec
  30 second output rate 4000 bits/sec, 1 packets/sec
     1003836 packets input, 174201781 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
    ...
     169446 packets output, 80281698 bytes, 0 underruns
     ....

有这个txloadrxload值,会以某种方式用于测量负载吗?

2个回答

答案取决于您真正要测量的内容。

负载(或利用率)可以表示为接收的数据量、传输的数据量或两者的总和。您选择哪一个部分取决于底层媒体。

您还需要决定是测量隧道中的流量,还是隧道使用的物理接口上的流量。后者将包括隧道开销,以及任何其他非隧道流量。

rxload/txload 类似于“滑动平均值” load-interval,但所使用的算法有一些特殊性;接口的输入/输出速率值也是如此。

此外,rxload/txload 值bandwidth与给定接口属性相关,该属性本身隐含地从接口的速度值中导出或用bandwidth接口上的命令手动覆盖

因此,在您的示例中,bandwidth 256隧道接口上的(在扩展中:256kbit/s)将导致一些非常高的 rx/txload 值,当该隧道接口上有 100Mbit/s 的流量时。

输入/输出速率或 rx/txload 适合人机交互使用,但它们可能有些偏差。例如,在以高吞吐量进行大/长传输load-interval之后,即使在大流量已经停止之后,输入/输出速率值也需要相当长的时间(比 更长)才能再次“冷却”。

对于编程使用,我建议像 SNMP 流量绘图员那样做:每隔一段时间(您选择的轮询间隔),使用 SNMP 读取接口ifInOctets/ifOutOctets(甚至更好的 64 位变体ifHCInOctets/ifHCOutOctets),并计算差异,然后报告您的轮询间隔。或者,将获得的值与接口的bandwidth属性(也可以通过 SNMP 访问)相关联,以获得百分比之类的东西。

建议阅读:https : //standalone-sysadmin.com/are-you-monitoring-your-switchports-the-right-way-1d3098ec8938

正如几周前我们的线程/聊天中所建议的那样 - 不要费心解析 CLI 输出来获取这些值。这就是 SNMP 的发明目的,您应该能够轻松找到合适的脚本/库/工具。