ASR920 und Ausgabe sinken - überraschenderweise scheint IPTV in Ordnung zu sein

Vielleicht ist meine Frage etwas ungewöhnlich, weil ich nicht frage, warum etwas nicht funktioniert. Stattdessen werde ich fragen, warum die Dinge in Ordnung zu sein scheinen.

Ich habe ASR-920-24SZ-IM mit 2x10G-Verbindungen an Upstream-ASR9ks angeschlossen. Das nachgeschaltete Gerät ist Cisco 4948E, das als Zugriffsgerät fungiert (verbunden über eine andere 10G-Verbindung). Die vom 4948E übergebenen Dienste sind Internetzugang, eine Reihe von E-LINEs und IPTV.

Uplinks werden mäßig genutzt - ~ 20% und 10%. Ich beobachte jedoch Leistungsabfälle an der Schnittstelle in Richtung 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

Da auf der ASR920-Schnittstelle in Richtung 4948E keine QoS-Konfiguration vorhanden ist, sollten an diesem Port 120 KB Puffer verfügbar sein. Wenn meine Mathematik korrekt ist, würde dies bedeuten, dass ASR920 in der Lage ist, Datenverkehr im Wert von ~ 0,1 ms während eines Leitungsraten-Bursts zu puffern, der von Upstream-10G-Verbindungen kommt.

Interessant ist, dass IPTV-Kunden oder Überwachungssysteme keine Probleme mit Multicast-Verkehr melden, der empfindlich auf Paketverluste reagiert. Jeder IPTV-Kanal ist ein 10-20-Mbit / s-Stream (variable oder konstante Bitrate) mit einer Paketgröße von 1358 Byte.

Wie ist es möglich, dass Multicast trotz Leistungsrückgängen nicht zu leiden scheint?

BEARBEITEN:

Nach 48 Stunden sehen die Zähler wie folgt aus:

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

Leider weiß ich nicht, um welchen Codec es sich handelt, aber ich werde versuchen, es herauszufinden.

Der Teststrom hat eine konstante Bitrate und das Intervall zwischen den Paketen beträgt 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

Momentan fällt mir nur eine Erklärung ein: Bursts sind kürzer als 500 us. Ich weiß, dass Output-Drops vorhanden sind und es> 100 us braucht, um den Drop zu verringern. Wenn die Bursts 200-300 us lang sind, führt dies zu Leistungsabfällen, sollte jedoch keinen Einfluss auf Multicast haben.

Im Folgenden stelle ich einige Ausgaben wie gewünscht zur Verfügung.

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

Der Befehl sh interfaces te0/0/27 switchscheint auf dieser Plattform nicht unterstützt zu werden.

cisco-asr

— mkurek
quelle

Welchen Codec verwenden Sie? h.264 SVC zufällig?

— Sergeyrar

Die Befehlsausgabe legt nahe, dass ~ 122.000 Pakete in nicht ganz 2 Stunden verworfen wurden. Das ist vielleicht gar nicht so viel. Wie viele Pakete wurden im selben Zeitraum übertragen?

— Marc 'netztier' Luethi

217201/50286674450 = 24E-6 oder 24 von 1.000.000 Paketen. Ich vermute, Sie würden es nicht bemerken.

— Ron Trunk

Nächste Woche werde ich zusätzliche Tests mit "schwererem" Strom durchführen und sehen, ob die Tropfen einen Einfluss haben. Ich bin mir jedoch sicher, dass dies ein wenig Abstimmung erfordert.

— mkurek

Welche Codeversion verwenden Sie?

— YLearn

Antworten:

Wie in den Kommentaren erwähnt, ist die Anzahl der Drops zwar hoch, im Vergleich zum Gesamtverkehr jedoch recht niedrig. Die Ausgabe-Drop-Rate beträgt 2,4e-5 oder 0,0024%. Wenn die Drops also in regelmäßigen Abständen auftreten, tritt bei Ihrem Test-Stream ungefähr alle 41,7.000 gesendeten Pakete ein fehlendes Paket auf. Selbst Multicast sollte keine Probleme haben, sich von einer so niedrigen Droprate zu erholen, und ein Endbenutzer wird wahrscheinlich nichts bemerken, worüber er sich beschweren könnte. Dies setzt auch voraus, dass einige oder alle Drops Multicast sind.

Sie scheinen auch zu verstehen, wie / warum die Tropfen auftreten, und betrachten Bursts als Quelle der Tropfen. Gibt es einen Grund, warum Sie glauben, dass dies der Fall ist? Sie haben weder Ihre Codeversion noch die Konfiguration aus dem ASR bereitgestellt, aber ich würde mich eher auf einen Fehler wie CSCuw45886 stützen , um die Ursache für Ihre Probleme zu sein.

— YLearn
quelle

Danke für deine Antwort. Ich verwende momentan 15,5 (3) S4. Ich denke, dass der von Ihnen erwähnte Fehler in dieser Version behoben werden sollte. Ich vermute, dass die Einbrüche durch starken Datenverkehr verursacht werden könnten, da wir dort viele Privatkunden haben und die Standardpuffergröße auf dieser Plattform relativ klein ist. Nach 5 Tagen beträgt die Output-Drop-Rate 0,04%. Warum nehmen Sie an, dass in regelmäßigen Abständen Tropfen auftreten?

— mkurek

@mkurek, ja, es sollte behoben werden (es sei denn, es wurde versehentlich wieder eingeführt), aber es kann andere Fehler geben. Ich mache keine Annahmen über Ihr Problem, aber Sie haben keine Informationen über die Art der Tropfen angegeben, unabhängig davon, ob sie regelmäßig oder in Schüben auftreten. Es scheint jedoch etwas schwierig zu sein, von ~ 30-35% (Ihre gemeldeten Uplinks plus a%) einer 10G-Verbindung, die verwendet wird, auf jeweils nur Mikrosekunden über 100% zu platzen. Vielleicht, wenn Sie 60% oder mehr drängten ...

— YLearn

Was Drops betrifft, die ständig / in Intervallen / abhängig von der Tageszeit auftreten ... Wird zufällig ein NMS-System ausgeführt, das SNMP-Drop-Count (oder Delta-of-Drop-Count über ein bestimmtes Abfrageintervall) sammelt und grafisch darstellt? )? Das Diagramm kann dazu beitragen, festzustellen, ob das Auftreten von Tropfen tatsächlich konstant ist, bezogen auf die Bürozeiten (dh Benutzeraktivität bezogen, möglicherweise nicht auf Multicast) oder ob es sich auf andere Muster bezieht (dh Multicast-Verkehr über einem bestimmten Schwellenwert).

— Marc 'netztier' Luethi

-2

Die Droprate war so niedrig, dass sie ignoriert werden kann

— Sanagi
quelle