16
Drops TX - Ursachenforschung
Hallo liebe Admins!
Hier gibts folgendes Problem:
Zwischen zwei Aruba Switchs entstehen gibts Drops TX, obwohl die Leitung nur schwach ausgelastet ist.
Es handel sich um einen Aruba 2540-24G-4SFP+ Switch (JL354A)
und als zweites Gerät um einen Aruba 2530-24G Switch (J9776A)
Die beiden Switchs sind per Kupfer verbunden.
Patchkabel wurde schon getauscht, ebenfalls anderer Ports versucht.
STP ist deaktiviert. Beide Switch verständigen sich auf einen 1GBit Link.
Der Paketpuffer ist bei einem Switch bei 26%, beim zweiten bei 4%. (sehr konstant)
CPU Last auf beiden ist ebenfalls sehr niedrig.
Die Switches wurden bereits durchgestartet und auf den letzten Firmwarestand aktualisiert.
Meine Frage dazu - wieso kommt es da zu Drops? Die Switch sollten ja eigentlich die Pakete nur dropen,
wenn der Buffer voll ist, oder bin ich da auf dem Holzweg? Vll. kann jemand von euch da Licht rein bringen.
Sollten noch Infos fehlen - bitte schreibt mir einfach.
Im Anhang noch ein Screenshot der Counter,
links der Aruba 2530, rechts der 2540er.
Hier gibts folgendes Problem:
Zwischen zwei Aruba Switchs entstehen gibts Drops TX, obwohl die Leitung nur schwach ausgelastet ist.
Es handel sich um einen Aruba 2540-24G-4SFP+ Switch (JL354A)
und als zweites Gerät um einen Aruba 2530-24G Switch (J9776A)
Die beiden Switchs sind per Kupfer verbunden.
Patchkabel wurde schon getauscht, ebenfalls anderer Ports versucht.
STP ist deaktiviert. Beide Switch verständigen sich auf einen 1GBit Link.
Der Paketpuffer ist bei einem Switch bei 26%, beim zweiten bei 4%. (sehr konstant)
CPU Last auf beiden ist ebenfalls sehr niedrig.
Die Switches wurden bereits durchgestartet und auf den letzten Firmwarestand aktualisiert.
Meine Frage dazu - wieso kommt es da zu Drops? Die Switch sollten ja eigentlich die Pakete nur dropen,
wenn der Buffer voll ist, oder bin ich da auf dem Holzweg? Vll. kann jemand von euch da Licht rein bringen.
Sollten noch Infos fehlen - bitte schreibt mir einfach.
Im Anhang noch ein Screenshot der Counter,
links der Aruba 2530, rechts der 2540er.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6439174569
Url: https://administrator.de/contentid/6439174569
Ausgedruckt am: 24.11.2024 um 14:11 Uhr
16 Kommentare
Neuester Kommentar
Moin,
ernsthaft jetzt? Du machst Dir bei 0,009 bzw. 0,133 Promille Drops Sorgen? Das ist imho ein vollkommen normaler und akzeptabler Wert.
hth
Erik
ernsthaft jetzt? Du machst Dir bei 0,009 bzw. 0,133 Promille Drops Sorgen? Das ist imho ein vollkommen normaler und akzeptabler Wert.
hth
Erik
Das ist durchaus normal. Es kann hier und da mal ein Paket kaputtgehen und das wird dann entspr. gedroppt.
Kann auch sein das da irgendwelche äußeren Einflüsse mit rein Spielen in form von irgendwelchen HF oder LF Störungen. Kann mich erinnern wir hatten mal ein defektes Schaltnetzteil was da ordentlich reingehauen hat was die TX/RX Verluste angeht. Aber selbst da haben wir nix mitbekommen da, je nach Protokoll, das ganze dafür ausgelegt ist.
Wenn die Verluste zu groß werden gibst natürlich Probleme aber bei der geringen Anzahl würde ich es gut sein lassen.
Nur mal nebenbei erwähnt: Dir ist aber schon bekannt das es hierfür Korrektur Mechanismen innerhalb der Protokolle gibt ? Weil gäbe es die nicht dann würde es keine Weitverkehrs Netze geben.
Aber mal ein paar fragen an dich:
Sind Port 1 und 23 die Uplink Ports worüber die Switches verbunden sind ?
Gibts irgendwo im Gebäude PowerLan ?
Hängen die Systeme an der selben Phase seitens des Stroms ?
Falls es einzelne PC´s sind dann wünsch ich dir viel Spaß beim suchen. Das geht wie gesagt von
defektem Netzteil über Minderwertige Kabel bin hin zu Sachen auf die du keinen Einfluss hast.
Gerade mal auf unseren 155 MBit Uplink geschaut. Da sinds knapp 0,5 bis 0.8% Drops.
Auf der Darkfiber ist´s sogar teilweise 1 % Verlust drauf und es geht noch alles ohne das es jemand merkt.
Wo die 1% auf der LWL Leitung herkommen kann uns keiner sagen. Bis zum POP ist alles ok. Wir leben damit. Leitung innerhalb der Specs und gut ist.
Kann auch sein das da irgendwelche äußeren Einflüsse mit rein Spielen in form von irgendwelchen HF oder LF Störungen. Kann mich erinnern wir hatten mal ein defektes Schaltnetzteil was da ordentlich reingehauen hat was die TX/RX Verluste angeht. Aber selbst da haben wir nix mitbekommen da, je nach Protokoll, das ganze dafür ausgelegt ist.
Wenn die Verluste zu groß werden gibst natürlich Probleme aber bei der geringen Anzahl würde ich es gut sein lassen.
Nur mal nebenbei erwähnt: Dir ist aber schon bekannt das es hierfür Korrektur Mechanismen innerhalb der Protokolle gibt ? Weil gäbe es die nicht dann würde es keine Weitverkehrs Netze geben.
Aber mal ein paar fragen an dich:
Sind Port 1 und 23 die Uplink Ports worüber die Switches verbunden sind ?
Gibts irgendwo im Gebäude PowerLan ?
Hängen die Systeme an der selben Phase seitens des Stroms ?
Falls es einzelne PC´s sind dann wünsch ich dir viel Spaß beim suchen. Das geht wie gesagt von
defektem Netzteil über Minderwertige Kabel bin hin zu Sachen auf die du keinen Einfluss hast.
Gerade mal auf unseren 155 MBit Uplink geschaut. Da sinds knapp 0,5 bis 0.8% Drops.
Auf der Darkfiber ist´s sogar teilweise 1 % Verlust drauf und es geht noch alles ohne das es jemand merkt.
Wo die 1% auf der LWL Leitung herkommen kann uns keiner sagen. Bis zum POP ist alles ok. Wir leben damit. Leitung innerhalb der Specs und gut ist.
Herzlichen Dank für die Antworten.
Ja, es sind Port 1 bzw. 23.
Dazwischen ist nur ein 5m langes, neues, geschirmtes Patchkabel. Ohne Einflüsse.mit reichlich Abstand verlegt.
Powerlan gibt es nicht.
Das mit der Phase muss ich noch abklären.
Ab welchen Drop Raten erachtet ihr es als problematisch?
Ja, es sind Port 1 bzw. 23.
Dazwischen ist nur ein 5m langes, neues, geschirmtes Patchkabel. Ohne Einflüsse.mit reichlich Abstand verlegt.
Powerlan gibt es nicht.
Das mit der Phase muss ich noch abklären.
Ab welchen Drop Raten erachtet ihr es als problematisch?
Hi,
Welche Firmware verwendest du konkret? Es gibt ja verschiedene Branches…
Wie sieht die Port Konfiguration aus?
Ist QoS ein Thema?
Magst du ein show run int vom Port machen?
Ich gehe mal davon aus, dass der Uplink überbucht ist - was hängt an Systemen auf den Switches?
VG
Welche Firmware verwendest du konkret? Es gibt ja verschiedene Branches…
Wie sieht die Port Konfiguration aus?
Ist QoS ein Thema?
Magst du ein show run int vom Port machen?
Ich gehe mal davon aus, dass der Uplink überbucht ist - was hängt an Systemen auf den Switches?
VG
Ohne Logs und Konfig schwer zu beantworten.
Moin,
Da habe ich mir noch nie Gedanken drüber gemacht. Problematisch wird es, wenn man es merkt, sprich, wenn das Netz lahmt.
Liebe Grüße
Erik
Da habe ich mir noch nie Gedanken drüber gemacht. Problematisch wird es, wenn man es merkt, sprich, wenn das Netz lahmt.
Liebe Grüße
Erik
Wenn zwei Switches direkt verbunden sind, dann ist jeder TX Drop ungewöhnlich.
Zumal die Ursache unbekannt scheint.
In meinen Netzwerken würde das meine volle Aufmerksamkeit erregen.
Zumal die Ursache unbekannt scheint.
In meinen Netzwerken würde das meine volle Aufmerksamkeit erregen.
Hi,
nochmal zurück: Was hängt dort an Geräten dran?
TX-Drops sind zumeist auf eine Uplink-Congestion zurückzuführen und vollkommen logisch.
Beispiel: Du hast zwei Clients auf Switch 1, die jeweils mit 1G angeschlossen sind und zwei Server auf Switch 2, die auch mit 2G angeschlossen sind. Schicken nun beide Clients zu beiden Servern Daten ist der Link zwischen den beiden Switchen nicht mehr ausreichend und es werden Pakete verworfen.
Wichtig: Die Pakete wurden vom Switch selbst verworfen - und das schon BEVOR diese aufs Kabel geschickt worden sind.
Gleiches passiert auch, wenn beispielsweise Limits (Broadcast-Limit, etc) gesetzt sind.
Oder wenn QoS zuschlägt..
Ein RX-Error kann beispielsweise auf eine fehlerhafte VLAN-Konfiguration hinweisen:
Beispiel: Switch 1 hat auf Port 1 die VLANs 1,2,3,4,5 anliegen, Switch 2 jedoch nur VLAN 1,2,3. Erhält es nun ein Paket für VLAN 5 wird dieses verworfen.
Oder wenn das Paket "defekt" ist - die MTU beispielsweise nicht passt, das Paket kleiner als die Mindestgröße (64 Bytes) ist,
nochmal zurück: Was hängt dort an Geräten dran?
TX-Drops sind zumeist auf eine Uplink-Congestion zurückzuführen und vollkommen logisch.
Beispiel: Du hast zwei Clients auf Switch 1, die jeweils mit 1G angeschlossen sind und zwei Server auf Switch 2, die auch mit 2G angeschlossen sind. Schicken nun beide Clients zu beiden Servern Daten ist der Link zwischen den beiden Switchen nicht mehr ausreichend und es werden Pakete verworfen.
Wichtig: Die Pakete wurden vom Switch selbst verworfen - und das schon BEVOR diese aufs Kabel geschickt worden sind.
Gleiches passiert auch, wenn beispielsweise Limits (Broadcast-Limit, etc) gesetzt sind.
Oder wenn QoS zuschlägt..
Ein RX-Error kann beispielsweise auf eine fehlerhafte VLAN-Konfiguration hinweisen:
Beispiel: Switch 1 hat auf Port 1 die VLANs 1,2,3,4,5 anliegen, Switch 2 jedoch nur VLAN 1,2,3. Erhält es nun ein Paket für VLAN 5 wird dieses verworfen.
Oder wenn das Paket "defekt" ist - die MTU beispielsweise nicht passt, das Paket kleiner als die Mindestgröße (64 Bytes) ist,
Sorry für die späte Antwort:
Hier noch weiterer Input:
In den Switches sind keine Limits gesetzt. (keine Storm Control, keine Loop Protection, etc)
Man kann auch in den Logs nicht erkennen.
Der 2540 ist ein "Core" Switch, wird teilweise von 10G Ports gespeist.
Am 2530 hängen eigentlich nur ein paar Clients (8, ein paar Drucker, etc).
Der Screenshot zeigt ca. die letzten 3 Tage an - rund 2,2 GByte ist da eigentlich keine Auslastung.
show run init gibt jeweils bei den Ports nur "untagged vlan" 1 aus
Hier noch weiterer Input:
In den Switches sind keine Limits gesetzt. (keine Storm Control, keine Loop Protection, etc)
Man kann auch in den Logs nicht erkennen.
Der 2540 ist ein "Core" Switch, wird teilweise von 10G Ports gespeist.
Am 2530 hängen eigentlich nur ein paar Clients (8, ein paar Drucker, etc).
Der Screenshot zeigt ca. die letzten 3 Tage an - rund 2,2 GByte ist da eigentlich keine Auslastung.
show run init gibt jeweils bei den Ports nur "untagged vlan" 1 aus
Vielleicht hilft dir folgendes weiter:
Bei dem 2530 könntest du einen Fault-Finder einrichten:
https://www.hpe.com/psnow/doc/a00091280en_us
Ab Seite 135.
z.B. einen over-bandwidth Fault-Finder
VG,
Florian
Bei dem 2530 könntest du einen Fault-Finder einrichten:
https://www.hpe.com/psnow/doc/a00091280en_us
Ab Seite 135.
z.B. einen over-bandwidth Fault-Finder
VG,
Florian
@110135 - danke, habe ich mir gleich angesehen und eingerichtet.
mit high sensitivity und all
Leider schreibt er nichts ins Log. Jetzt lass ich nebenbei gerade ein Monitoring laufen (Observium).
mit high sensitivity und all
Leider schreibt er nichts ins Log. Jetzt lass ich nebenbei gerade ein Monitoring laufen (Observium).
Statusupdate:
Das Monitoring zeigt eine Auslastung auf den Ports im Schnitt von ~8Mbits,
Spitze sind ~80 Mbit/s.
Ich werd mal Anfangen, die Switches testweise auszutauschen, mal schauen,
wie es sich dann verhält.
Das Monitoring zeigt eine Auslastung auf den Ports im Schnitt von ~8Mbits,
Spitze sind ~80 Mbit/s.
Ich werd mal Anfangen, die Switches testweise auszutauschen, mal schauen,
wie es sich dann verhält.
Statusupdate:
Den Aruba 2530 Switch hab ich nun durch einen Cisco SG220-50P ersetzt.
Es verhält sich nun so, dass der 2540er weiterhin Drops auf dem Port hab,
der Cisco SG220 erfasst jetzt keine Drops, sondern der Zähler RMON Oversize Packets steigt auf diesem Port.
Auf beiden Switchs sind Jumbo Frames deaktivert, MTU Size am Cisco ist bei den Standard 1500,
der Arbua hat lt. Dokumentation bei deaktivierten Jumboframs 1522 (inkl. VLAN) - also 1518 Bytes.
Kann das ev. durch die unterschiedliche MTU Size kommen? Eigentlich hängen nur Geräte mit 1500 MTU auf dem Arbua Switch, ich moment kann ich mir nicht erklären, worher die zu großen Pakte kommen.
Den Aruba 2530 Switch hab ich nun durch einen Cisco SG220-50P ersetzt.
Es verhält sich nun so, dass der 2540er weiterhin Drops auf dem Port hab,
der Cisco SG220 erfasst jetzt keine Drops, sondern der Zähler RMON Oversize Packets steigt auf diesem Port.
Auf beiden Switchs sind Jumbo Frames deaktivert, MTU Size am Cisco ist bei den Standard 1500,
der Arbua hat lt. Dokumentation bei deaktivierten Jumboframs 1522 (inkl. VLAN) - also 1518 Bytes.
Kann das ev. durch die unterschiedliche MTU Size kommen? Eigentlich hängen nur Geräte mit 1500 MTU auf dem Arbua Switch, ich moment kann ich mir nicht erklären, worher die zu großen Pakte kommen.
Zitat von @fritzkarl85:
Kann das ev. durch die unterschiedliche MTU Size kommen? Eigentlich hängen nur Geräte mit 1500 MTU auf dem Arbua Switch, ich moment kann ich mir nicht erklären, worher die zu großen Pakte kommen.
Die RMON Statistik lässt sich doch pro Interface anzeigen, somit siehst du doch von welchem Port die zu großen Pakete kommen, und somit auf das verursachende Gerät das da dran hängt ...Kann das ev. durch die unterschiedliche MTU Size kommen? Eigentlich hängen nur Geräte mit 1500 MTU auf dem Arbua Switch, ich moment kann ich mir nicht erklären, worher die zu großen Pakte kommen.
Wenn Trunk dann Port Mirror aktivieren und Wireshark-Trace machen, und schon ist das geklärt.
Also, ich hab nun am Aruba Switch am Trunk Port Mirroring aktiviert und den mit Wireshark mitgeschnitten -
der Counter im Switch steigt weiter langsam an, aber die größten Pakte haben 1514 Bytes - also nichts übergrößes?
Schlau werd ich aus dem ganzen nicht...
der Counter im Switch steigt weiter langsam an, aber die größten Pakte haben 1514 Bytes - also nichts übergrößes?
Schlau werd ich aus dem ganzen nicht...
Erlaube auf dem Port mal größere Paket-Größen dann müssten diese auch im Trace auftauchen.
