Beitragsbaum

 

Vorwort

Pakete die discarded werden sind kein gutes Zeichen. Sobald man Discards auf einem Interface bemerkt, sollte man diesen nachgehen und die Ursache dafür finden. Denn Discards können, je nach Masse, erhebliche Auswirkungen auf das Netzwerk verursachen. Im Endeffekt werden Pakete gedropt, die nicht vom Switch verarbeitet  werden, weil diese beispielsweise fehlerhaft sind oder der Packet Buffer voll ist. Meiner Meinung nach kann man anhand von Discards viel über die Stabilität eines Netzwerkes aussagen.

 

Einblick in die Infrastruktur

Wir haben mehrere Force10 Switches für unsere BladeCenter Infrastruktur im Einsatz. Diese sind meistens gestackt und verbinden die Blades mit dem restlichen Netzwerk. Angebunden sind die Force10 über einen 40Gbit Portchannel an einen Cisco Nexus 9500 Switch. Die 10Gbit Interface werden ausschließlich für die Blades verwendet. Soweit so gut.

 

Das Problem mit den Discards

Allerdings habe ich seit ein paar Wochen massenweise Discards auf sämtlichen Interfaces der Force10 Switches. Betroffen ist hier allerdings nur der Inbound Traffic der diese Discards aufweist. Rückschlüsse lassen sich jedoch nur schwer finden, da die Anzahl der Discards je nach Interface unterschiedlich groß ausfällt. So habe ich auf manchen 10Gbit Ports nur 200-400 Discards und dann jedoch auch Ports mit 16.000-20.000 verworfenen Paketen. Am schlimmsten betroffen ist der Portchannel (Uplink) Richtung Nexus 9500. Dieser hat mehr als 43.000.000 Discards!

Das Schlimmste kommt jetzt erst noch. Die Angaben beziehen sich auf eine Zeitspanne von gerade mal sechs Tagen.

Ich wollte direkt sicherstellen, dass es sich bei dem Problem nur um die Force10 Switche in einem BladeCenter beschränkt. Dies war jedoch nicht der Fall. Ich fand schnell in zwei anderen BladeCentern die selben Probleme mit den Force10 Switches. Das Lustige dabei ist allerdings, dass genau die gleichen Interfaces mit fast der genau gleichen Anzahl an Discards betroffen sind. Obwohl diese nicht miteinander verbunden oder zusammenhängen. Bitte was!?

 

Die Nadel im Heuhaufen

Ich musste erstmal mit dem Cursor die Zahl markieren um die Stellen zu erfassen. Kein Witz, dass ist erstmal ein Moment des Schweigens. Woher stammen so viele Discards an einem Interface binnen sechs Tagen.

Das Problem an dieser Stelle ist die Definition von Discards. Grundsätzlich können discarded Pakete erst einmal so gut wie alles sein. Auch getaggte Frames dessen VLAN auf einem Trunk nicht zugelassen ist, sind im Endeffekt Discards. Oder ein Protokoll welches nur die eine Seite spricht und die andere es nicht kann oder nicht möchte.

Auf der Gegenseite, der Nexus 9500, sehe ich auf dem Interface Richtung Force10 gar keine Fehler. Weder auf dem Inbound noch auf dem Outbound sind in irgendeiner Form Discards oder ähnliches anzutreffen. Somit tritt das Problem erst ab dem Portchannel des Force10 Switches auf. Alleridngs handelt es sich hier um eine direkte Verbindung der zwei Netzwerkgeräte. Dazwischen ist kein Switch oder Medienkonverter, einfach gar nichts.

 

Meine Ansätze

Tja, was macht man, wenn man nichts findet? Ganz einfach, sämtliche Dinge ausprobieren um das Problem zu lösen. Daher habe ich folgende Handlungen durchgeführt:

  • Sämtliche Logs durchwühlt, den CAM beobachtet, die Konfiguration überprüft und auf Fehlverhalten geachtet
  • Die Force10 Switche neugestartet (Klingt lächerlich, hat sich aber schon oft bewährt)
  • Testweise die Trunks auf beiden Seiten komplett aufgemacht (keine Beschränkung von VLAN’s mehr)
  • Software Image neu installiert (Falls korrupt oder beschädigt)
  • Software Image geupgradet (Um eventuell einen Bug ausschließen zu können)
  • Wireshark Mitschnitte erstellt (um Rückschlüsse auf den Traffic zu erhalten)

 

Das alles hat rein gar nichts gebracht. Da ich und mein Kollege so langsam nicht mehr weiter wussten, haben wir Kontakt mit Dell aufgenommen und dort unser Problem geschildert.

 

Der Fall bei Dell

Der Techniker seitens Dell konnte uns erst einmal auch nicht weiterhelfen und somit überbrachte ich ihm die gewünschten Informationen, welche er für die Analyse benötigt.

Ich halte euch natürlich auf dem Laufenden und werde neue Informationen und Kenntnisse unter diesem Beitrag editieren. Ich bin gespannt, wie Dell uns helfen wird und was die Ursache des Problems ist.

 

+++ EDIT 07.06.19 – Ticket bei Dell +++

Laut dem Dell Techniker liegt es an unserer Software Version, wodurch die Discards verursacht werden. Wie das sein kann? Das fragte ich mich auch und wollte eine Erklärung und die habe ich auch bekommen. Ich zitiere:

„Hier kurze Erklärung: Bei OS9 Version 9.13.X.X werden Discard Counters nach RFC Empfehlung implementiert. Das heißt praktisch, dass zum Beispiel auch LLDP Pakete (die legitim gedropt werden) dazu zählen. Ab FW-Version 9.14.0.0 wird das anderes umgesetzt und zu Discards zählen nur Pakete die aufgrund von vollem Buffer discarded werden.“

 

Die Antwort hatte ich mir nicht erhofft. Warum sollten legitim gedropte Pakete im Interface als discarded aufgeführt werden? Allerdings müsste man auch hier wieder definieren, was genau mit „legitim gedropte Pakete“ wirklich gemeint ist. Beispielsweise werden vom Force10 Interface keine Drops von der ACL als Discard anerkannt.

Da es mich brennend interessiert hat, was genau die RFC unter Discards versteht und wie diese gehandelt werden sollten, habe ich mal etwas nachgeschlagen. Die „RFC 2863- The Interface Group MIB“ erklärt Discards anhand von Beispielen sehr ausführlich und genau. Am besten man sucht nach „Discard“ und hangelt sich somit durch das Dokument. Dort ist, soweit ich das gelesen habe, nie die rede von „legitimen Drops, welche den Discard Counter inkrementieren lässt.

Also was sind Discards für Dell? Das habe ich dann doch nochmal genauer nachgefragt und folgende Grafik erhalten:

Das erklärt ein wenig wie der Discard Counter bei Force10 zumindest agiert, allerdings lässt sich über die Sinnhaftigkeit diskutieren. Also der Discard Counter wird getriggert wenn ein unbekanntes Protokoll empfangen wird. Soweit so gut, dass steht sogar in der RFC. Das LLDP viel Traffic im Netzwerk viel vorkommt ist klar, aber 43 Millionen Discards in vier Tagen? Das sind ~7 Millionen pro Tag, ~299.000 pro Stunde, ~4980 pro Minute und ~82 pro Sekunde!? Das kann nicht nur LLDP sein, da muss mehr discarded werden und das massig.

Das Problem liegt angeblich an der Software und diese soll auf die aktuellste Version geupgradet werden. Ich hatte zuvor auf eine andere 9.13(x.x) Version geupgradet, allerdings ist der Discard Prozess auch dort noch anders umgesetzt. Nun muss das BladeCenter leer geräumt werden und dann werden wir die Version 9.14(1.5) auf die Switche spielen. Ich melde mich dann wieder!

 

+++ EDIT 11.06.19 – Ticket bei Dell +++

Für das Upgrade der Force10 auf 9.14(1.5) wurde das BladeCenter und damit die Blades leergeräumt. Kurz davor hatten wir einen neuen Rekord an Discards auf dem Portchannel erreicht . Ganze 9 Millionenen Discards in zwei Stunden.

Somit habe ich das neue Image auf das „Boot-System B:“ geschrieben und dies als „Main Boot-System“ festgelegt. Somit würde nach dem Reload die Switche die neue Firmware auf dem Stack im „Boot-System B:“ installieren und auch von diesem booten.

Soweit so gut, allerdings dauerte das Upgrade schon viel zu lange zu dem Zeitpunkt. Mehr als eine halbe Stunde lang nach dem vermeintlichen Reload habe ich keine Antwort auf meinen Ping bekommen. Komisch. Also schaute ich auf das Chassis Management Controller (CMC) nach, ob ich dort fündig werde und was musste ich feststellen? Das CMC hat die statische IP-Konfiguration der Force10 verworfen. Ohne jeglichen Grund aus Jux und Dollerei.

Also habe ich die IP-Konfiguration wieder eingetragen und siehe da, es pingt wieder. Wow. Meiner Meinung nach ist das System mehr Testumgebung als ein Produkt zum Verkauf an den Kunden, aber naja.

Nichtsdestotrotz lief der Upgradeprozess erfolgreich durch und die Force10 Switche haben vom „Boot-System B:“ aus das neue Image 9.14(1.5) gebootet.

Siehe da, keine Discards mehr. Auch nach ein paar Stunden waren keine zu sehen. Ich habe das nun ein paar Tage lang beobachtet und kann das Problem nicht mehr reproduzieren. Aber ist es damit gelöst? Ich habe diesbezüglich drei Fragen an Dell gestellt.

  1. Was hat sich denn nun genau geändert, dass der Counter nicht mehr inkrementiert?
  2. Warum fallen nun keine Discards mehr an, wenn es vorher in Millionenhöhe vorgefallen ist?
  3. Wurden denn wirklich Pakete discarded oder wurde nur der Counter getriggert und es passierte nichts? Beziehungsweise werden nun Pakete weiterhin discarded und nicht mehr hochgezählt?

 

Denn laut der Grafik vom ersten Update am 07.06.2019 werden zwar imemr noch die Pakete discarded aber der Counter wird nicht mehr inkrementiert. Aber ist das wirklich so? Wir warten einmal gespannt auf die Antwort seitens Dell.

Außerdem habe ich mal auf den „Reload-Bug“ und die Löschung der damit verbundenen statischen IP-Konfiguration aufmerksam gemacht… Vielleicht ist dies ja ein bekanntes Problem oder doch nur normale Prozedur?

 

+++ EDIT 12.06.19 – Ticket bei Dell +++

Dell ist relativ zügig was die Reaktionszeit auf Tickets angeht und somit wurden meine drei Fragen auch schon beantwortet. Nun kann ich beruhigt schlafen und das Thema abschließen.

  1. Was hat sich denn nun genau geändert, dass der Counter nicht mehr inkrementiert?
    -> „Siehe Tabelle unten. Wir haben nur verändert, welche verworfenen Pakete in die „discards“-Statistik eingehen, weil die bisherige Implementierung nicht der Beschreibung im https://tools.ietf.org/html/rfc2863 entspricht.“
  2. Warum fallen nun keine Discards mehr an, wenn es vorher in Millionenhöhe vorgefallen ist?
    -> Es werden im Normalen Betrieb immer Pakete verworfen. Darunter zählen z.B. Steuerungspakete, die im Switch regulär nicht weitergeleitet werden und am Switch-Port direkt verworfen werden (LLDP, STP, LACP etc.). Wir haben die Arten von verworfenen Paketen an die RFC oben angepasst, sodass eben weitaus mehr Pakete in diese Statistik eingehen.
  3. Wurden denn wirklich Pakete discarded oder wurde nur der Counter getriggert und es passierte nichts? Beziehungsweise werden nun Pakete weiterhin discarded und nicht mehr hochgezählt?
    -> Es werden tatsächlich Pakete verworfen. „discards“ sind alle Pakete, die fehlerfrei übertragen wurden, aber aus anderen Gründen verworfen werden (flow-control, VLAN nicht erlaubt, STP blocking port etc.) Das ist in den meisten Netzwerken normal.

Soweit war mir das klar, allerdings wollte ich mir das nochmal bestätigen lassen. Das Pakete wie LLDP, BPDU’s, etc discarded werden, ist mir schon bewusst, hatte ich zuvor ja oben auch bereits erwähnt. Für mich ist der letzte Absatz entscheidend und da stimme ich voll und ganz zu.

„Da die Implementierung nach RFC den „discard“-Zähler zwar logisch korrekt war, aber dieser Zähler dann nicht mehr als Indikator für ein Problem taugte, haben wir die Pakettypen für diesen Zähler nochmals angepasst.

Nun sehen wir anhand der „discards“, ob ein Port oder die Segmente dahinter überlastet sind, da nur noch Pakete gezählt werden, die mangels Packet Buffer im Switch verworfen werden.“

 

Fazit

Am Ende gab es kein richtiges Problem. Discarded Pakete sind in der Regel nicht gut, allerdings kommt es auf die Impelementierung des Counters an. In diesem Fall hat der Counter auch Pakete als Discard gelistet, welche nicht fehlerhaft oder durch mangelenden Packet Buffer verworfen wurden. Zu einem Problem wird das ganze erst dann, wenn man troubleshooten möchte. Der Discard Counter dient dann nicht mehr als Indikator für Probleme im Netzwerk.

Schlussendlich kommt man um ein Firmware Upgrade höher als 9.14(x.x) nicht herum. Erst dann werden die Interface Statistiken nach dem neuen Design angezeigt und umgesetzt.

 

over & out,

jonsch