Output Drops auf der seriellen Schnittstelle: Bessere Warteschlangen- oder Output Queue-Größe?


16

Bei Internet-Edge-Routern, die eBGP mit mehreren Carriern und iBGP miteinander kommunizieren, sind alle Schnittstellen auf LAN- und WAN-Seite mit Ausnahme eines seriellen Voll-DS3-Routers (~ 45 Mbit / s) auf jedem Router von GE. Obwohl ich glaube, dass ich auf den seriellen Schnittstellen - im Bereich von 3 bis 10 Mbit / s - kaum ausgehenden Datenverkehr sende, sehe ich konstante OQD-Werte (Output Queue Drops). Ist die wahrscheinliche Erklärung, dass es wirklich stoßartigen Verkehr gibt, den ich nicht sehe, da das Ladeintervall mindestens 30 Sekunden beträgt und die SNMP-Abfrage den Durchschnitt des Verkehrs über 5 Minuten berechnet , sodass diese den Stoß nicht ausleuchten?

Die Plattform ist ein Cisco 7204VXR NPE-G2. Serielles Queuing ist FIFO .

Serial1 / 0 ist aktiv, das Leitungsprotokoll ist aktiv
  Hardware ist M2T-T3 + pa
  Beschreibung: -entfernt-
  Die Internetadresse lautet abcd / 30
  MTU 4470 Byte, BW 44210 Kbit, DLY 200 usec,
     Zuverlässigkeit 255/255, txload 5/255, rxload 1/255
  Encapsulation HDLC, CRC 16, Loopback nicht eingestellt
  Keepalive-Set (10 Sek.)
  Die Wiederanlaufverzögerung beträgt 0 Sekunden
  Letzte Eingabe 00:00:02, Ausgabe 00:00:00, Ausgabe hängt nie
  Letzte Löschung der "show interface" -Zähler 00:35:19
  Eingabewarteschlange: 0/75/0/0 (Größe / max / Tropfen / Flushes); Gesamtleistung sinkt: 36
  Warteschlangenstrategie: FIFO
  Ausgabewarteschlange: 0/40 (Größe / max)
  30 Sekunden Eingangsrate 260000 Bits / Sek., 208 Pakete / Sek
  30 Sekunden Ausgaberate 939000 Bits / Sek., 288 Pakete / Sek
     410638 Pakete eingegeben, 52410388 Bytes, 0 kein Puffer
     Empfang von 212 Sendungen, 0 Runts, 0 Giganten, 0 Throttles
              0 Parität
     0 Eingabefehler, 0 CRC, 0 Frame, 0 Overrun, 0 ignoriert, 0 Abbruch
     515752 ausgegebene Pakete, 139195019 Bytes, 0 Unterläufe
     0 Ausgabefehler, 0 Applikationen, 0 Schnittstellenresets
     0 Ausgabepufferfehler, 0 Ausgabepuffer wurden ausgetauscht
     0 Trägerübergänge
   rxLOS inaktiv, rxLOF inaktiv, rxAIS inaktiv
   txAIS inaktiv, rxRAI inaktiv, txRAI inaktiv

24 Stunden später werden Tausende von OQD zeigen. Wir schieben jeden Tag um 3 Uhr morgens mehr Verkehr raus. Vielleicht gibt es hier etwas Verkehr, dem ich nicht genug Gewicht beimesse.

Last clearing of "show interface" counters 1d01h
Input queue: 0/75/0/158 (size/max/drops/flushes); Total output drops: 12049

Ich würde gerne mehr ausgehenden Datenverkehr auf den DS3 lenken, aber nicht mit meiner Sorge um den OQD. Der Tier-2-ISP hinter dem DS3 verfügt über POPs, die bei über 6 Tier-1-Anbietern als Peering-Punkte fungieren. Daher ist es die Idee, den Datenverkehr so ​​schnell wie möglich mit dem Client im Netz zu verbinden, im Gegensatz zu unserem primären ISP auf dem GE, der ein Tier-1-Anbieter ist , müssen sich aber auf den Peering-Austausch vorarbeiten. Eingehender Datenverkehr ist kein Problem.

Gibt es in dieser Situation eine bessere Warteschlangenstrategie als FIFO? In den Cisco-Dokumenten zum Löschen von Eingabe- und Ausgabewarteschlangen wird das Erhöhen der Größe ausgehender Warteschlangen nicht empfohlen, da sich die Pakete bereits auf dem Router befinden. Es ist besser, sie bei der Eingabe zu löschen, damit TCP die App zurückdrosseln kann. Auf unseren GE-Links ist viel Bandbreite vorhanden, sodass der Eingang nicht wirklich gedrosselt werden muss. Auf diesen Routern sind keine Richtlinienzuordnungen vorhanden. 90% des ausgehenden Datenverkehrs stammt aus unseren HTTP-Antworten. der größte Teil davon stammt von FTP und SMTP. Die GE-Verbindungen übertragen 50-200 + Mbit / s.

Würden Sie Anpassungen des Ausgabewarteschlangengrößenpuffers empfehlen? Diese seriellen Schnittstellen sind unsere Backup-Links, die ich aus dem oben genannten Grund (sofern gültig) lieber verwenden würde, aber mit meinen BGP-Richtlinien, die versuchen, diese serielle Schnittstelle nicht zu überlasten (die die meiste Zeit sehr unterlastet zu sein scheint), in Einklang zu bringen.

Antworten:


13

Sie haben recht, Sie würden die Burstigkeit bei SNMP nicht so leicht erkennen. 1GE kann 1,48Mpps senden, so dass es sehr, sehr wenig Zeit braucht, um die 45Mbps zu überlasten, die weniger als 75kpps verarbeiten können.

Wenn Ihr Eingang 1GE ist und der Ausgang 45 Mbit / s beträgt, muss der Überlastungspunkt von 45 Mbit / s offensichtlich Pakete verwerfen. Das ist normal und wird erwartet. Wenn Sie die Puffer erhöhen, wird die Verzögerung erhöht.
1GE benötigt 0,45 ms, um 40 1500B IP-Frames zu senden. Dies ist derzeit die Menge an Bursts, die Sie verarbeiten können. Das Entfernen der Daten mit 45 Mbit / s dauert jedoch bereits 10 ms.

Wenn Sie kein akutes Problem haben, würde ich wahrscheinlich nichts dagegen tun. Wenn jedoch ein Teil des Datenverkehrs für das Löschen geeigneter ist als der andere, sollten Sie FIFO durch klassenbasierte Warteschlangen ersetzen. Angenommen, Sie möchten Prioritäten setzen, damit mehr FTP gelöscht wird und weniger VoIP.
Dann ist es auch sinnvoller, den FTP-Verkehr stärker zu puffern, da er nicht wirklich empfindlich auf Verzögerungen reagiert.

Wenn Sie Ihr Glück mit tieferen Puffern versuchen möchten, sollte Folgendes ausreichen:

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

Dies würde 50 ms Puffer auf Serial1 verursachen und es Ihnen ermöglichen, bis zu 2,25 ms Burst von einer einzelnen Gige-Schnittstelle zu verarbeiten.


Der primäre Ein- und Ausgang ist 1GE auf unseren primären Pfaden, wobei ein gewisser Prozentsatz des Verkehrs über die DS3s geleitet wird. Bearbeitetes Q, um zu zeigen, dass 90% des ausgehenden Datenverkehrs HTTP-Antwortverkehr ist, wobei FTP und SMTP den Rest ausmachen.
Generalnetworkerror

Ich würde es vermeiden, den DS3 zu verwenden, wenn der Gige verfügbar ist, da die Pufferung Verzögerungen verursacht. Alle genannten Anwendungen scheinen jedoch sehr verzögert und verlusttolerant zu sein.
Ytti

Der andere Grund, den ich für den Versuch, mehr von DS3 zu verwenden, nicht erwähnte, besteht darin, Burst-Ladungen auf den GE WAN-Verbindungen zu vermeiden, die> 100 MB einleiten. Obwohl wir täglich über 100Mb platzen, war es (noch) nicht lange genug, um eine Rolle zu spielen.
Generalnetworkerror

Sie könnten mehr Verkehr zum DS3 leiten und sogar Paketverluste reduzieren, indem Sie mehr Verzögerung einführen. Wenn Sie jedoch damit rechnen, Ihre Zugriffszahlen zu steigern, wird das Problem immer schlimmer. Denken Sie daran, dass Ethernet nie etwas anderes ist als 100% oder 0%, nur wie lange es 100% ist, variiert. Sie werden also immer die Bursts puffern, die von Ihrem Hochgeschwindigkeits-1GE-Netzwerk verursacht werden.
Ytti

2
Mein Grund für 200 Pakete ist die Verzögerung, die erforderlich ist, um sie mit 45 Mbit / s zu versenden. Dies entspricht einer Verzögerung von 50 ms, die für Datenanwendungen immer noch tolerierbar ist. Sie sollten sich fragen, wie lange Sie die Verzögerung tolerieren werden, und dann den Puffer angeben, um dieses Ziel zu erreichen. In deiner Situation würde ich einfach das Gige benutzen.
Ytti

8

Die OQDs werden normalerweise durch eines von zwei Dingen verursacht:

  1. Sie nutzen den Link nicht mehr. mit entweder konstant hoher Auslastung oder stoßartigem Verkehr.

  2. Auf die Benutzeroberfläche wird eine Richtlinienzuordnung angewendet, die so konfiguriert ist, dass sie den gesamten oder einen Teil des Datenverkehrs überwacht oder gestaltet

  3. Es liegt ein Fehler in der Schnittstelle vor. Sehen Sie sich die Fehlerzähler ( show interface Serial1/0 counters errors) an und prüfen Sie, ob die Pakete aufgrund eines Fehlers nicht verworfen werden.

Sie könnten eine Richtlinienübersicht erstellen (falls Sie noch keine haben), um beispielsweise Ihrem unternehmenskritischen Verkehr eine eigene Warteschlange zuzuweisen, die Vermeidung von Staus im regulären Verkehr (WRED) zu aktivieren oder einfach nur eine faire Warteschlangenbildung im Verkehr zu ermöglichen dass die Bandbreite zwischen den Flüssen geteilt wird, die die Schnittstelle übertragen.

Wie Sie bereits erwähnt haben, besteht eine weitere Option darin, die Größe der Ausgabewarteschlange auf der Schnittstelle zu erhöhen. Wenn Sie jedoch eine Richtlinienzuordnung verwenden, ist dies ohnehin nicht erforderlich, da die Richtlinie andere Unterwarteschlangen erstellt.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.