07.03.2017

19093

RX Dropped Pkts Problem

Hallo zusammen,

ich habe ein Problem mit unserem Client Switch. Dieses ist ein D-Link DGS-1510-52, welches mit unserem Server Switch HP2920 Verbunden ist. Es sind 4 Port gebündelt.
Nun sehe ich in der Überwachung der Ports des D-Links, dass bei den gebündelten Ports viele Pakete verloren gehen. Beim HP ist das nicht der Fall.

Kann man hier etwas unternehmen? Oder ist das zu vernachlässigen?

Hier noch ein paar Daten:

D-Link: Portkanal-Info
LACP Zeitüberschreitung: Long
Betriebsmodus: Active
LACP Staus bndl
Port Prioritär: 32768

HP: Portkanal-Nachbarinfo
Partnersystem-ID: 38656,6C-C2-17-05-97-00
Partner PortNr. für alle port erkannt
Partner LACP-Zeitüberschreitung: Long
Partnerbetriebsmodus: Active
Partner Port Prioritär: 0

Über eure Hilfe würde ich mich freuen.

Gruß Micha

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 331384

Url: https://administrator.de/forum/rx-dropped-pkts-problem-331384.html

Ausgedruckt am: 22.12.2024 um 08:12 Uhr

14 Kommentare

Neuester Kommentar

Kann man hier etwas unternehmen?

Oder ist das zu vernachlässigen?

Die Frage kann man dir logischerweise nicht beantworten, da du mit keinem Wort sagst wieviel Packet Drops pro übertragenen Pakets auftreten.
Das sollte dir doch auch selber klar sein das wir bei so einer oberflächlichen Pauschalaussage auch nur raten können. Ein Prozentsatz von <1% ist sicher tolerabel. Mehr nicht.
Du kannst ja sehen das die HP Gurke scheinbar keine Probleme hat.
Man müsste mal sehen was die Drops sind bzw.was der D-Link als Dropped bezeichnet. Das können kaputte Frames sein (Runts, Giants, Collisions) aber auch welche mit falschen Tags usw. oder welche die der Switch aufgrund seiner schlehcten Performance nicht forwarden konnte und so weggeschmissen hat.
Verdächtig ist das das einseitig ist und auf der anderen Seite nicht auftritt. Das zeigt eher auf einen Fehler im D-Link. Häufig ist das eine fehlerhafte Optik (bei Fiber) oder bei Kupfer defekte Kabel oder Transceiver.
Hier muss man forschen.

Hast du mal geprüft ob es auf den einzelnen Links zu Überlast Situationen kommt ??
LACP LAGs unterliegen einem Hashing Verfahren. Es ist KEIN homogenes Per Packet Vertelen der Daten. Die Flows werden je nachdem wie du die Hashberechnung eingestellt hast nach Mac Adressen oder IP Adressen gemacht und auf die 4 Links verteilt.
Es ist möglich das ein Link 80% der Last trägt und die 3 anderen den Rest. Davon ist meist auszugehen wenn ein Ende nur wenig IP oder Mac Adressen hat und so wenig Entropie bei den Endadressen vorliegt die die Verteilung bedingt.
Weiteres dazu erklären dir diese Threads:
Cisco LAG-LACP an Synology RS3614xs+ Bonding Bandbreite zu niedrig
LAG zwischen SG300-Switches macht Probleme. Wer weiß Rat?

Du solltest also zuerst mal die Verteilung des Traffics auf den Links checken um zu sehen ob die Drops ggf. mit höher belastetn Links korrelieren. Das würde dann schon mehr Licht auf die Uhrsache werfen.
STG z.B. visualisiert das in einer grafischen Form über SNMP
http://leonidvm.chat.ru

Hi aqui,

danke für die schnelle Antwort.

Ich muss dazu sagen, dass ich ein Leihe bin und mich ganz wenig mit Switches auskenne. Daher auch die Pauschale Aussage. Unter Statistik -> Port habe ich meinen Trunk

Port RX TX
Rate Gesamt Rate Gesamt
Byte/Sek Pakete/Sek bytes Pakete Byte/Sek Pakete/Sek bytes Pakete
eth1/0/1 283861 215 24349651446 28445631 1479 17 2215921263 17050705
eth1/0/2 193751 238 318184956594 648076679 22112 258 114530794690 809970529
eth1/0/3 17329 31 29670754786 29933274 364 2 872343664 9028464
eth1/0/4 12763 51 30213697743 48046583 31973 166 7647757244 41579844

Unter details von Port 2 anzeigen, sehe sehe ich die folgenden Infos

RX rate 269270 bytes/sec
TX rate 73247 bytes/sec
RX bytes 318099552789
TX bytes 114503836818
RX rate 444 packets/sec
TX rate 505 packets/sec
RX packets 647917645
TX packets 809773452
RX multicast 383587
RX broadcast 1100672
RX CRC error 0
RX undersize 0
RX oversize 0
RX fragment 0
RX jabber 0
RX dropped Pkts 63842
RX MTU exceeded 0
TX CRC error 0
TX excessive deferral 0
TX single collision 0
TX excessive collision 0
TX late collision 0
TX collision 0

Unter Zählerfehler wird nichts auf die genannten (Runts, Giants, Collisions) hingewiesen.

eth1/0/2 Zählerfehler
Align-Err 0
Fcs-Err 0
Rcv-Err 0
Undersize 0
Xmit-Err 0
OutDiscard 0
Single-Col 0
Multi-Col 0
Late-Col 0
Excess-Col 0
Carri-Sen 0
Runts 0
Giants 0
Symbol-Err 0
SQETest-Err 0
DeferredTx 0
IntMacTx 0
IntMacRx 0

SNMP ist aktiviert und STG habe ich bereits ausprobiert, jedoch kann ich hier nichts herauslesen. Ich weiss nicht, wie ich den Grafen auf den einzelne Port einstellen kann. Evtl haben die OIDs etwas damit zu tun, jedoch kenne mich damit nicht aus.

zum SNMP kann ich folgende Einstellugen vornehmen;

SNMP
Globale SNMP-Einstellungen
SNMP Linkchange Trap-Einstellungen
SNMP-Ansichtstabellenkonfiguration
SNMP Community-Tabelleneinstellungen
SNMP-Gruppentabelleneinstellungen
SNMP Engine ID Lokal Einstellungen
SNMP-Benutzertabelleneinstellungen
SNMP-Host-Tabelleneinstellungen

Ich glaube, dass ich den Trunk mal deaktiviere und schaue ob sich dadurch Veränderungen ergeben. Evtl. reicht die 1gig-Verbindung aus, hier sind hauptsächlich Clients für RDP-Verbindungen angeschloßen.

Gruß Micha

Ich muss dazu sagen, dass ich ein Leihe bin

So so, dich kann man also mal ausleihen ??!!

http://www.duden.de/rechtschreibung/Laie

Ich weiss nicht, wie ich den Grafen auf den einzelne Port einstellen kann.

Vergiss das. Wenn du keinerlei Ahnung hast dann würde das hier den Rahmen sprengen dir das zu erklären. Nur so viel. JA es ist die OID !
Du musst die Interface OID des Interfaces da eintragen was du überwachen willst. Du kannst STG 4mal starten und kannst dann so den Traffic alle 4 LAG Port ssehen.
Die OIDs entsprechen der Ethernet Standard MIB. Das sollte dir als Erklärung helfen !
http://cisconet.com/traffic-analysis/traffic-monitoring/247-quick-realt ...
1.3.6.1.2.1.2.2.1.10.x = auch bei dir Grün (inbound)
1.3.6.1.2.1.2.2.1.16.x = auch bei dir Blau (outbound)
Du musst nur die Interface Indexierung deines Switches rausbekommen. X = die Port Indexnummer.
Im einfachsten Fall mal mit 1,2 3 usw. nach Port Nummern versuchen.
Das es keine Packetfehler sind legt den Schluss nache das du dort einen tagged Link betreibst und tagged VLANs überträgst was ja durchaus Sinn macht wenn man mehrere VLANs auf den Switches betreibt.

Was häufig falsch gemacht wird ist die Tatsache das du z.B. 10 VLANs auf dem HP betreibst und diese 10 VLANs auch alle tagged auf dem Link zum D-Link überträgst.
Dort brauchst du aber z.B. nur die VLANs 1,2 und 3 und hast die auf dem Link auch als tagged eingetragen.
Wenn nun aber der HP einen Frame aus dem VLAN 7 schickt sendet er ihn ka am Port raus mit einem VLAN 7 Tag.
Dieser Frame kommt am D-Link an und da der kein VLAN 7 hat kan er damit nix anfangen und dropped den Frame.

Kann es also sein das du ggf. ein VLAN Mismatch hast zw. den HP Links und den korrespondirenden D-Link links.
Das wäre ebenso ein Indiz dafür das der Drop Counter hochgeht und zwar nur einseitig.

Ich glaube, dass ich den Trunk mal deaktiviere und schaue ob sich dadurch Veränderungen ergeben.

Das ist vollkommen sinnfrei und zeigt eher dein erschreckend schwaches Netzwerk Wissen. Du agierst hier hilflos im freien Fall mit Trial und Error

Bringt meist nix.
Nimm dir jemanden an die Hand der wirklich weiss was er tut und dann macht ihr euch strategisch auf die Suche.
Wie würdes du das finden wenn dein Autohändler bei der nächsten Wartung deines Autos sagt er hat da den Blumenhändler von nebenan als Vertretung der das an deinem Auto macht.
Deine Reaktion kann man sich denken....
Also: hol dir Hilfe und erspar dir die grauen Haare und sinnfreies Basteln.

Zitat von @aqui:

Ich muss dazu sagen, dass ich ein Leihe bin

So so, dich kann man also mal ausleihen ??!!

http://www.duden.de/rechtschreibung/Laie

Na klar! Für Geburtstage, für Hochzeiten, für Feiertage usw.

Ich weiss nicht, wie ich den Grafen auf den einzelne Port einstellen kann.

Super. Das ging ja einfacher als gedacht. Ich hab gestern nochmal die Zähler gelöscht und seit gestern Abend sind wir wieder bei ca. 1801 rx drops. Du hast gemeint, dass bis 1 % unbedenklich. Bei drei von 4 Ports ist das auch der Fall. Da liege ich bei ca. 0,5 % (RX Packets zu RX dropped PKts). Jedoch bin ich beim dem Port 2 bei 1,12 %. Dieser Port hat auch die ganze Auslastung.

Das es keine Packetfehler sind legt den Schluss nache das du dort einen tagged Link betreibst und tagged VLANs überträgst was ja durchaus Sinn macht wenn man mehrere VLANs auf den Switches betreibt.

Genau das ist mir schleierhaft. Hier ist nichts getagged, alle Port sind untagged und was die Vlans betrifft, so gibt es nur ein default-Vlan, das war es aber auch. --> ok und ja, ich habe keine Ahnung was tagged oder untagged heißt.

Was häufig falsch gemacht wird ist die Tatsache das du z.B. 10 VLANs auf dem HP betreibst und diese 10 VLANs auch alle tagged auf dem Link zum D-Link überträgst.
Dort brauchst du aber z.B. nur die VLANs 1,2 und 3 und hast die auf dem Link auch als tagged eingetragen.
Wenn nun aber der HP einen Frame aus dem VLAN 7 schickt sendet er ihn ka am Port raus mit einem VLAN 7 Tag.
Dieser Frame kommt am D-Link an und da der kein VLAN 7 hat kan er damit nix anfangen und dropped den Frame.

Kann es also sein das du ggf. ein VLAN Mismatch hast zw. den HP Links und den korrespondirenden D-Link links.
Das wäre ebenso ein Indiz dafür das der Drop Counter hochgeht und zwar nur einseitig.

Ich glaube, dass ich den Trunk mal deaktiviere und schaue ob sich dadurch Veränderungen ergeben.

Das ist vollkommen sinnfrei und zeigt eher dein erschreckend schwaches Netzwerk Wissen. Du agierst hier hilflos im freien Fall mit Trial und Error

Bringt meist nix.

Habe doch gesagt, dass ich keine Ahnung habe. Ist aber alles halb so schlimm, denn hier hängen nur unsere Clients dran und bis dato hatte noch keiner wirkliche Probleme. Das ist mir zufällig aufgefallen und Bedarf noch keinen Einsatz eines Profis.

Nimm dir jemanden an die Hand der wirklich weiss was er tut und dann macht ihr euch strategisch auf die Suche.

Hab dich gefunden. Bzw. du hast mich gefunden!

. Daumen hoch auf eine guten Zusammenarbeit.

Wie würdes du das finden wenn dein Autohändler bei der nächsten Wartung deines Autos sagt er hat da den Blumenhändler von nebenan als Vertretung der das an deinem Auto macht.
Deine Reaktion kann man sich denken....
Also: hol dir Hilfe und erspar dir die grauen Haare und sinnfreies Basteln.

Glückwunsch...deine Netzwerkkentnisse haben sich um 100% gesteigert. SNMP ist schon großes Kino

Dieser Port hat auch die ganze Auslastung.

Das war zu erwarten, denn das liegt am Hashing Verfahren bei LACP LAGs.
Deinen Grafiken oben (danke fürs Posten hier...!) zeigt mal wieder eindeutig wie ungranular die Verteilung ist bei Billigswitches die nur Mac- oder IP Adressen in die Berechnung einfliessen lassen und wenn wenig Mac- oder IP Adressen beidseitig des Links vorhanden sind, es also eine sehr sehr geringe Entropie gibt.
Wenn du keinerlei Sgementierung machst sprich VLANs und alles ein dummes, flaches Netzwerk ist, dann müssen es physische Probleme sein.
Ggf. kann das auch durch ein schadhaftes Kabel ausgelöst werden. Testweise also mal tauschen.
Spannend wäre auch zu wissen ob der Fehler mitwandert. Wenn du also diesen Link einfach mal ziehst und dann ein anderer diesen LAG Link Traffic übernimmt ob dort auch die Counter wieder hochgehen.
Das würde dann zeigen das der Fehler nicht Port bedingt ist also auf die HW bezogen.
Da sich die restlichen 3 Links ja langweilen kannst du gefahrlos den mal abziehen. Die anderen werden dann sofort übernehmen und am STG kannst du dann wunderschön sehen wer denn den Traffic abfackelt...und dort natürlich dann die Counter beobachten.

Ja cool, mit ein paar Unterstützungen geht das ganz schnell

. Bin auch schon viel weiter, auch was tagged und untagged betrifft. Nun weiß ich auch was du mit "..dummes, flasches Netztwerk.." meinst. Was noch interessant ist, dass der drop-counter nahezu identisch bei allen 4 Ports ist. Ich werde aber das mit dem Kabel versuchen und schaue mir die Grafiken an.
Wenn die anderen 3 Port sich langweilen, dann könnte ich doch wirklich den Trunk reduzieren. Ich kann leider auch nicht abschätzen ob eine durchschnittliche Auslastung bei 167,8kb jetzt für den 1GB Port viel ist (denke nicht). Große Daten werden eigentlich nicht übertragen.

Müssen die beiden Hashing Verfahren gleich sein. Also (HP)MAC- MAC (Dlink) oder geht bei einem (HP)MAC und bei anderem (Dlink)IP oder beides zusammen oder ist das bei uns nicht relevant. Können beide aktiv sein oder muss einer passive der andere aktiv sein.

Gruß

Die Hashing Verfahren können unterschiedlich sein. Das stört nicht, im Gegenteil. Die Hash Berechnung welchen Link das Pärchen nimmt passiert immer pro Seite. Es kann also sein das das Paket hin einen anderen Linkweg nimmt als zurück, was per se nicht falsch oder schlecht ist.
Was das LACP anbetrifft sollten wenn möglich IMMER beide Seiten im Active State sein.
Die beiden Enden kaspern dann selber aus wer active und passive wird.
So kann es niemals passieren, das man aus Versehen mal 2 passive Seiten zusammensteckt die dann nie einen LAG bilden könnten.
In ganz seltenen Fällen werden sich beide Partner mal nicht einig. Dann hilft es eine Seite dediziert active zu nehmen und eine passive. Mit welcher es dann klappt ist Testsache.
Wie gesagt, das ist sehr selten, kann aber mal passieren.
In sofern ist es immer sehr wichtig das man auf BEIDEN Switchseiten den LACP Status ansieht und checkt das beide Seiten einen LAG immer als "Operational" oder "UP" anzeigen.

Hallo zusammen,

Ich glaube, dass ich den Trunk mal deaktiviere und schaue ob sich dadurch Veränderungen ergeben. Evtl. reicht die
1gig-Verbindung aus, hier sind hauptsächlich Clients für RDP-Verbindungen angeschloßen.

Nimm doch einfach eine 10 GBit/s Verbindung mittels eines DAC Kabels und gut ist es.

Wenn die anderen 3 Port sich langweilen, dann könnte ich doch wirklich den Trunk reduzieren. Ich kann leider auch nicht
abschätzen ob eine durchschnittliche Auslastung bei 167,8kb jetzt für den 1GB Port viel ist (denke nicht). Große Daten
werden eigentlich nicht übertragen.

Wenn eine Leitung voll ist, wird die nächste angefangen!

Müssen die beiden Hashing Verfahren gleich sein. Also (HP)MAC- MAC (Dlink) oder geht bei einem (HP)MAC und bei anderem
(Dlink)IP oder beides zusammen oder ist das bei uns nicht relevant. Können beide aktiv sein oder muss einer passive der andere
aktiv sein.

Das eine findet auf Layer2 (MAC) statt und das andere auf Layer3 (IP), also das sollte schon zueinander passen.

Ich würde das auch ganz anders versuchen zu lösen, denn der DGS1510 ist ein Layer3 Switch mit 2 SFP+ Ports und dort
kann man den Server dann mittels 10 GBit/s anbinden! Und wenn zwischen den Switchen ein 4er LAG (LACP) läuft und
der Server "nur" mittels 1 GBit/s angebunden wird dann kann es eben auch dort wieder zu Störungen kommen!!!

Die Switche werden ja nicht die ganze zeit getauscht und wieder anders eingesetzt, aber genau deswegen kann man
auch ein statisches LAG aufsetzen und dann Round Robin als Methode zur Lastverteilung benutzen, dann werden
auch in der regle alle Leitungen gleichzeitig benutzt!

Gruß
Dobby

Oha Dobby !!
Bei 167,8 kbit/s Durschnittslast ist mit Kanone auf einen Sandfloh bei 10G. Das ist wohl eher mega kontraproduktiv, denn da würde auch ein einzelner 1G Link vollends ausreichen. Es sei denn der TO hat zuviel Geld

2 aber auf alle Fälle und dann wäre die Verteilung auch besser.

Danke für die Info. 10GB ist vermutlich übertrieben, da ich zusätzliche Module beim HP brauche. Aber wenn das mit dem statischen LAG funktioniert, dann hätte ich auch keine Probleme damit. Muss mal gucken, ob die beiden Switche diese Methode "Round Robin" unterstützen und wie ich zu dieser komme. In einem Beitrag von aqui stand es glaube ich mal dabei (thx). Aber ich lerne ja häppchenweise.

Danke für die Info. 10GB ist vermutlich übertrieben,

Naja, also bei 10 GBit/s gibt es, sicherlich auch Protokoll abhängig, aber dort kann man irgend etwas zwischen 2 GBit/s und 4 GBit/s
als Netto-Durchsatz erwarten und dann die zu 4 GBit/s aggregierte Leitung des LAG (statisch) und dann sollte dort kein Flaschenhals
mehr vorhanden sein. Denn egal wie man es hin oder her biegt bei Packet Drops oder loss sind immer zu viele Daten die nicht schnell
genug durch einen oder mehrere Ports gehen, oder eben nicht schnell genug verarbeitet werden.

Gruß
Dobby

aber dort kann man irgend etwas zwischen 2 GBit/s und 4 GBit/s

Sorry aber das wäre grottenschlecht für 10G.
Bei 10G kann man wie bei allen anderen Geschwindigkeiten dann auch mitdesten 8Gig erwarten !!!
Alles dadrunter wäre schlecht.

Ja würde ich auch sagen, dass 2-4 gig bei einer 10ner Leitung etwas zu wenig wäre.

Was mich aber noch mehr interessieren würden ist das Thema mit diesen statischen Trunks und wie ich das am besten anstelle. Wird die Round Robin Methode beim statischen Trunk automatisch erstellt. Ich habe gelesen, dass beim statischen trunk kein Protokoll eingesetzt wird.

Beim HP soll ich anscheinen auch noch wählen können zwischen statischen LACP und statischen Trunk. Des weiteren muss man anscheinen auch aufpassen und spanning-tree und so ein "gedöns"

aktivieren (zwecks Loop-Disaster usw). Hab schon alles aktiviert, was zu aktivieren ist.

dass beim statischen trunk kein Protokoll eingesetzt wird.

Ja, das ist richtig. Das wird OHNE das LACP Protokoll realisiert. Hier muss man also gewaltig aufpassen das hinter den LAG Ports auch wieder LAG Ports der anderen Seite sind, da die Siwtches das nicht mehr selber merken können.
Logisch das die andere Seite dann auch statische LAGs machen muss. Andernfalls würde sonst deren LACP ins Nirwana laufen...logisch !

Beim HP soll ich anscheinen auch noch wählen können zwischen statischen LACP und statischen Trunk.

Ziemlich viele Konjunktive in dem Satz...

Sieh ins Handbuch, da sollte das stehen. Switches die auch statische LAGs haben können das je.
Ist ja auch logisch denn je nachdem ob man LACP macht oder eben statisch entscheidet man sich ja automatische zwischen beiden Optionen.
Die Aussage ist also ein bischen sinnfrei von dir....

Des weiteren muss man anscheinen auch aufpassen und spanning-tree und so ein "gedöns" aktivieren

Das klingt nicht gerade vertrauenserweckend bei dir das du technisch weisst was du da eigentlich machst. Aber die Antwort lautet ja ! In jedem Falle sollte man bei statischen LAGs immer wenn irgendmöglich Spanning Tree aktiv haben um sich vor versehentlichen Loops zu schützen. LACP kann dafür ja dann nicht mehr sorgen...klar !

Hab schon alles aktiviert, was zu aktivieren ist.

Klingt auch nicht gerade sehr professionell...

gelöst Frage Netzwerke

Mehr von chhadm

Monatliche Sicherheitqualitäsrollups für Windows Server R2 64bit + Win 7 schlagen fehlchhadm - 5 Kommentare

TS Farm richtig nach DNS Round Robin einrichtenchhadm - 5 Kommentare

Apple oder Android in Windowsumgebungchhadm - 2 Kommentare

Brocade 300 VS Ubiquiti US-16-XGchhadm - 5 Kommentare

Heiß diskutiert