ASR920 和输出下降 - 令人惊讶的是,IPTV 似乎工作正常

网络工程 cisco-asr
2021-07-15 01:58:33

也许我的问题会有点不寻常,因为我不会问为什么有些东西不起作用。相反,我会问为什么事情似乎工作正常。

我将 ASR-920-24SZ-IM 通过 2x10G 链路连接到上游 ASR9ks。下游设备是 cisco 4948E 作为接入设备(通过另一条 10G 链路连接)。移交给 4948E 的服务是互联网接入、一堆 E-LINE 和 IPTV。

上行链路被适度利用 - 约 20% 和 10%。但是,我观察到 4948E 接口上的输出下降。

 Last clearing of "show interface" counters 01:52:25
 Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 122398
 Queueing strategy: fifo

由于 ASR920 接口上没有 QoS 配置到 4948E,因此该端口上应该有 120kB 的缓冲区可用。如果我的数学是正确的,这意味着 ASR920 能够在来自上游 10G 链路的线速突发期间缓冲大约 0.1 毫秒的流量。

有趣的是,IPTV 客户和监控系统都没有报告多播流量的任何问题,这对丢包很敏感。每个 IPTV 频道是 10-20 Mbps 流(可变或恒定比特率),数据包大小为 1358 字节。

尽管输出下降,多播似乎没有受到影响怎么可能?

编辑:

48 小时后计数器如下所示:

Last clearing of "show interface" counters 2d05h
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 1217201
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 576849000 bits/sec, 243662 packets/sec
30 second output rate 3706610000 bits/sec, 374245 packets/sec
 29523227831 packets input, 8591353468212 bytes, 0 no buffer
 Received 44508 broadcasts (0 IP multicasts)
 0 runts, 0 giants, 0 throttles 
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
 0 watchdog, 977069 multicast, 0 pause input
 50286674450 packets output, 62508590137876 bytes, 0 underruns

不幸的是,我不知道它是什么编解码器,但我会尽力找出答案。

测试流是恒定比特率,数据包之间的间隔是 500 us。

Timestamp: 0.523377 Diff: 0.000544 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.523866 Diff: 0.000489 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.524424 Diff: 0.000558 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.524935 Diff: 0.000511 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.525474 Diff: 0.000539 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.525977 Diff: 0.000503 Sender: 10.200.200.207:34620 Size:1316

目前我想到的只有一种解释:爆发时间短于 500 us。我知道输出下降在那里,需要> 100 us 才能下降。如果突发的长度为 200-300 us,则会导致输出下降,但不应影响多播。

下面我根据要求提供了一些输出。

ASR920#show interfaces te0/0/27 stats
TenGigabitEthernet0/0/27
      Switching path    Pkts In   Chars In   Pkts Out  Chars Out
           Processor          0          0      22354    8324046
         Route cache          0          0          0          0
   Distributed cache          0          0          0          0
               Total          0          0      22354    8324046

sh interfaces te0/0/27 switch此平台似乎不支持命令

2个回答

正如评论中所指出的,虽然下降计数看起来很高,但与总流量相比,它实际上很低。输出丢弃率为 2.4e-5 或 0.0024%,因此如果丢弃定期发生,您的测试流大约每发送 41.7k 个数据包就会遇到一个丢失的数据包。即使是多播也应该可以轻松地从如此低的丢包率中恢复,最终用户可能不会注意到任何可抱怨的事情。这也假设任何或所有丢弃都是多播的。

您似乎还试图了解下降是如何/为什么发生的,并将爆发视为下降的来源。你有什么理由相信这是真的吗?你还没有提供你的代码版本或 ASR 的配置,但我更倾向于像CSCuw45886这样的错误作为你问题的根源。

掉率低到可以忽略