HP Switches (V1920) konfigurieren... oder gleich was neues kaufen?

[willy-goergen 0]

Wann kommen die Externen denn mit dem Leihswitches zum Testen?

 

Ist STP wirklich aktiviert oder doch deaktiviert? Oder hat es nur den Anschein?

 

Ist die Firmware auf dem aktuellen Stand?

 

Wenn du mich ehrlich fragst, brauchen die vielleicht gar nicht mehr wegen dem Netzwerkproblem zu kommen. Ich habe heute eine Alternative abgeklopft, die mir genau das als Leihgerät zur Verfügung stellt, was ich möchte. Es stellt sich bei der Sache für mich schon viel eher die Frage, ob die erstere Firma überhaupt eine Entlohnung für ihre Leistung erhalten sollte. Die war finde ich bestenfalls ungenügend. Immerhin bin ich derjenige, der nach kompetenter Hilfe gefragt hat. Ob ich das mache, ist eine andere Sache. Man könnte jetzt auch argumentieren, wären die nicht gewesen, wüsste ich nicht, was man alles falsch machen kann... Aber das war ja nicht der Sinn der Sache.

 

STP ist wirklich deaktiviert. Komplett und überall, seit heute Mittag. Ich dachte, ich lasse es drauf ankommen. Notfalls hätte ich die Switches neu gestartet und die ursprüngliche Konfiguration (mit STP) wäre wieder geladen worden.

 

Die Firmware ist auf dem aktuellsten Stand. Hatte die Switches vor ca. zwei Wochen damit geflasht. Seitdem gibt es auch nichts neueres.

bearbeitet 18. Juni 2015 von willy-goergen

[DocData 85]

Ich warte gespannt auf die Fehlermeldung.

[willy-goergen 0]

Du kannst sie haben.

18	1.517763000	HewlettP_d9:e9:f2	Spanning-tree-(for-bridges)_00	STP	64	Conf. Root = 0/0/d0:7e:28:d9:e9:e4  Cost = 0  Port = 0x800d [ETHERNET FRAME CHECK SEQUENCE INCORRECT]

Diese Fehlermeldung kommt alle paar Sekunden, sobald STP aktiviert ist. Ist gerade nicht sehr schön formatiert. Sorry....

bearbeitet 18. Juni 2015 von willy-goergen

[DocData 85]

Und wo ist da die Fehlermeldung?

[willy-goergen 0]

Die Frage würde ich zurück geben. Was würdest du da sehen?

 

Irgendwie passen da die Prüfsummen der übertragenen Pakete nicht ganz. Was sollte man ggf. daraus schließen?

[DocData 85]

Die Frage würde ich zurück geben. Was würdest du da sehen?

 

Irgendwie passen da die Prüfsummen der übertragenen Pakete nicht ganz. Was sollte man ggf. daraus schließen?

Ich sag das ja nur ungern, aber da ist keine Fehlermeldung. Ich denke du spielst auf das "[ETHERNET FRAME CHECK SEQUENCE INCORRECT]" an. Das ist kein Fehler, das ist normal. Man kann Wireshark sagen, dass es die Frame Checksumme nicht prüfen soll ("Validate the Ethernet checksum if possible"). Das Artefakt was du da beobachtest und für einen Fehler hälst liegt darin begründet, dass die FCS durch die NIC berechnet und an den Frame angehangen wird. Wireshark bekommt das nicht mit.

 

Ansonsten ist es natürlich völlig korrekt das du die STP Pakete alle 2 Sekunden siehst. Du hast da ein stinknormales BPDU Paket gesnifft. Wenn du STP für das Problem hälst, dann konfiguriere es endlich ordentlich auf allen Komponenten. Ich habe hier in meinem Lab 1910-24G, 1910-8G und 5820. Wenn ich nur die beiden 1910-24G und 1910-8G betrachte (werden bei mir für ein paar Thin Clients, Lab Firewall etc. verwendet), dann funktionieren die einwandfrei - sogar mit aktiviertem RSTP.

bearbeitet 18. Juni 2015 von DocData

[willy-goergen 0]

Ich sag das ja nur ungern, aber da ist keine Fehlermeldung. Ich denke du spielst auf das "[ETHERNET FRAME CHECK SEQUENCE INCORRECT]" an. Das ist kein Fehler,...

 

Vielen Dank für den sehr guten Beitrag! :)

Da wäre ich so einfach nie drauf gekommen. Du hast wahrscheinlich recht. Aber gibt's irgendwo eine Quelle, anhand der ich das für mich nochmal selbst nachvollziehen kann? Falls du was wüsstest, wäre das gut.

 

Wo wäre in dem Fall optimalerweise ein Ansatzpunkt für das Problem gewesen? Das Betrachten eventueller Topologieänderungen im Syslog des Switches? Die passieren mit aktiviertem STP bei mir leider viel zu häufig.

 

Mit der Deaktivierung von STP habe ich wohl einen ziemlichen Glückstreffer gelandet. Es gab heute von einigen Kollegen sehr positives Feedback. So schnell wie jetzt, wäre das Firmennetz noch nie gewesen, was für sie insgesamt eine ziemliche Erleichterung darstellt.

 

Leider trifft das nicht für alle zu. Das ERP-System läuft zwar sehr viel zügiger, aber es gibt immer noch ein Problem bei Kollegen, die im Hintergrund recht anspruchsvolle SQL-Abfragen am Laufen haben. Manchmal werden sie sehr schnell ausgeführt. Meistens aber nicht. Meint ihr, da gibt es noch eine Möglichkeit, das über die QOS-Regeln in den Switches etwas zu optimieren?

 

So wie das im Moment für mich aussieht, hab ich da noch einiges an Konfigurationsarbeit vor mir. Einfach anstöpseln und gut ist, sieht für mich auch gerade nach einem schlechten Witz aus.

bearbeitet 19. Juni 2015 von willy-goergen

[mba 133]

Wo werden die SQL-Abfragen ausgeführt?

Auf dem Client, dem Server oder Switch?

[willy-goergen 0]

Die Abfragen werden vom betreffenden Client ausgeführt. Der Zeit, die der Server zum Antworten braucht, ist sehr unterschiedlich.

[mba 133]

Immer der selbe Client? Stets die die gleichen Abfragen`?

[magheinz 110]

Port A sendet Packet Z. (erste Ausgabe in Wireshark)

Port B empfängt Packet Z. (zweite Ausgabe in Wireshark, als Retransmission oder Duplicate Ack hinterlegt)

 

Ergo, Switch ist kaputt. :D

Eigentlich bin ich auch b***d und hätte das gleich sehen müssen. Wenn man nur den eingehenden Verkehr auf den Ports überwacht, sieht die Sache schon wesentlich angenehmer aus. Nicht ganz fehlerfrei, aber schon viel viel besser.

Mittlerweile weiß ich, warum für die Externen sämtliche Switches bei uns kaputt wären. Sowas hätte denen überhaupt nicht passieren dürfen. Was war geschehen? Sie hatten einen Monitoring-Port eingerichtet, auf dem der komplette eingehende und ausgehende Verkehr sämtlicher anderen Ports gespiegelt wurde. Vielleicht sieht einer schon den Fehler?

 

Welche Geschwindigkeit hat der Monitoringport?

Mich würde mal die Systemauslastung des Coreswitches under Unterverteilung mit den Swervern interessieren.

Dann würde ich mal versuchen auszuschliessne ob die SQL-Probleme wirklich Netzwerkprobleme sind. Eventuell ist auch einfach der SQL-Server ausgelastet.

Eventuell ist auch der Serverswitch ausgelastet, das wäre eine Erklärung warum sowohl CRM als auch SQL hängen.

Sind diese Heavyuser(CRM+SQL) an der gleichen Unterverteilung?

Ist diese eventuell an der Grenze?

Ist die Verbindung Unterverteilung<->Coreswitch eventuell ausgelastet?

Um wieviel sind die Uplinks überbucht? Ich sehe 18Clients+Server an einer Unterverteilung aber nur einen Uplink zum Coreswitch. Sind das 22*1G und der Uplink macht dann auch nur 1G?

 

Server+Clients gemeinsam an einer Unterverteilung finde ich ungeschickt.

 

Mal eine Anekdote zu Netzwerkproblemen:

Situation: Alles Glasfaser (singlemode) Zum Testen wurde von gebäude A zu Gebäude B gepatcht und direkt wieder zurück. Es ging darum eine 10G-Verbindung zu testen. So hatten wir die doppelte Länge im Test was eine gewisse Sicherheit bringen sollte. Beide Geräte waren somit in einem Raum und das Testen war einfacher.

 

Jetzt wurden die Testgeräte abgeschaltet und es wurden schon mal die Patches gesteckt.

 

Folge:

Totaler  Netzwerkausfall

Die Fehleranalyse führte zu den Bladeswitchen die einfach 30Sekunden nach einschalten zusammenbrachen. Es ging kein Traffic mehr darüber.

Erst mal Workaround über 1G-Verbindungen gebaut damit die Leute arbeiten konnten. Weitere Fehleranalyse sollte Nachts erfolgen. Externe Techniker fanden keine Fehler, IBM wollte am nächsten Morgen neue Bladeswitche vorbeibringen.

Diese Lieferung hatte ich noch mal verschoben da mir zwei gleichzeitig und identisch aussehende Fehlker zu unwahrscheinlich waren. Mein Tipp war immer Spanning-Tree, wegen der 30Sekunden. Also habe ich noch mal mein soziales Netzwerk aktiviert und diverse Experten draufschauen lassen/mit denen geredet. Keiner hat einen Fehler in der Konfig gefunden.

Letzter verzweifelter Lösungsversuch: Kollen der keinerlei Ahnung von dem Test und von Netzwerk überhaupt hat(typo3-Admin) mit in den Serverraum geschleppt: "Testumgebung ist abgeschaltet, Diese SFPs sind die Testverbindung. Kommt dir irgendwas komisch vor?" Kollege: "Da ist ein Link!".

Der Satz hat alles gesagt was gesagt werden musste. Das war die Testverbindung, die musste tot sein. Im anderen Gebäude geschaut und gesehen das der Testpatch noch steckte und somit der SFP wirklich keine Verbindung zum Netz hatte aber zu sich selbst. Quasi ein "Lichtkurzschluss".

 

Lehre daraus: Wenns nicht mehr weiter geht, einfach mal das Vorhaben und die Massnahmen jemandem erklären der noch nicht betriebsblind ist und schauen ob der auf Widersprüche stösst (Gerät abgeschaltet, trotzdem Link)

 

 

Ansonsten: Wir hatten ca 200-300 Miniswitche im Haus (4-6Port+Glasuplink). Dumme Geräte. Wenn die kaputt gehen legen die gerne den ganzen Netzwerkabschnitt lahm.

[DocData 85]

Wo wäre in dem Fall optimalerweise ein Ansatzpunkt für das Problem gewesen? Das Betrachten eventueller Topologieänderungen im Syslog des Switches? Die passieren mit aktiviertem STP bei mir leider viel zu häufig.

Du hast Topology Changes? Wie oft kommen die vor?

 

Mit der Deaktivierung von STP habe ich wohl einen ziemlichen Glückstreffer gelandet. Es gab heute von einigen Kollegen sehr positives Feedback. So schnell wie jetzt, wäre das Firmennetz noch nie gewesen, was für sie insgesamt eine ziemliche Erleichterung darstellt.

Das ist Murks. Du behebst ein Symptom, nicht das Problem.

 

Mal etwas zum Thema "Der Switch ist evtl. ausgelastet":

 

Selbst die Popel-Switches machen auf der Backplane ~ 100 Gb/s und bei 64 Byte Paketen schleust der ~77 Millionen Pakete pro Sekunde dadurch. Man kann vielleicht einen oder mehrere Ports auslasten, aber nicht den ganzen Switch. Sollte ein Port ein Bottleneck sein, dann sieht man aber auch das relativ schnell.

[magheinz 110]

Also ich hab schon switche gesehen die bei 100% systemlast waren. Allerdings Layer3 ciscos.

 

Der gezeigte Netzwerkaufbau kommt mir irgendwie nicht schlüssig vor.

Meiner Meinung nach gehören die Server auf einen extra switch oder alternativ direkt an den Coreswitch. Genau wie der DSL-uplink.

 

und die "unbekannte" Verbindung. Das sieht man doch am switchport auf der konsole/web oder einfach am Kabel/SFP/Gbic etc.

 

wenn ich so gar keine Ahnung hätte was mein Vorgäbnger gemacht hat und was ich da habe würde ich in einer Wochenendaktion, eventuell mit externer Hilf das gabze einmal neu machen. Danach hätte man erst mal einen definierten Zustand was die Verkabelung angeht und was die switchkonfig angeht. Danach könnte man dann ordentlich nach dem Fehler suchen der teilweise nicht mal zwangsweise was mit dem Netzwerk an sich zu tun hat.

[DocData 85]

Also ich hab schon switche gesehen die bei 100% systemlast waren. Allerdings Layer3 ciscos.

Aha... Und wie wahrscheinlich ist es, dass die genannten Switches wegen ein paar BPDU Paketen schlapp machen? Eher unwahrscheinlich... Zudem würde sich das Problem anders äußern.

 

Der gezeigte Netzwerkaufbau kommt mir irgendwie nicht schlüssig vor.

Meiner Meinung nach gehören die Server auf einen extra switch oder alternativ direkt an den Coreswitch. Genau wie der DSL-uplink.

KISS. In dem Konstrukt ist es total egal wo Server und DSL angeschlossen werden. Das ist ein Mininetzwerk.

bearbeitet 20. Juni 2015 von DocData

[willy-goergen 0]

Ich bin heute ein bisschen weiter gekommen und vielleicht auf die Ursache des Problems mit den vielen Topologieänderungen bei aktiviertem STP gekommen.

 

An den Switches hatte ich heute RSTP mit BPDU-Protection konfiguriert. Alle Ports, an denen Server oder Clients hängen, habe ich als Edge-Ports konfiguriert. Die Ports, an denen die Uplinks hängen, habe ich als "Not Set" konfiguriert. Die Einstellungen habe ich gespeichert. An den Ports, an denen Clients und Server hängen, habe ich keine BPDUs erwartet. Zuerst ging auch alles, scheinbar

 

Danach habe ich den Switch im Serverraum neu gestartet. Nun gingen die Probleme los. Der Emailserver und mein eigener Arbeitsrechner wurden vom Switch (BPDU-Protection) geblockt.

 

Die Rechner hatten BPDUs für Topologieänderungen und für die Konfiguration schicken wollen. Als Ursache hat sich ein überbrückter Netzwerkadapter herausgestellt. Auf dem Server hab ich das für VPN, auf meinem Arbeitsrechner für VirtualBox.

Auf meinem Arbeitsrechner habe ich die BPDU-Protection aktiviert gelassen und die Netwerkbrücke gelöscht. Danach hat das Switch den Port wieder freigegeben.

Für den Server habe ich den Port am Switch erst mal freigegeben. Der gibt grade wieder munter BPDUs ins Netzwerk. Das ist mir auch schon vor einer Woche aufgefallen.

 

Aus dem Handbuch von HP zum Switch werde ich nicht dazu nicht schlau. Kann ich den Port überhaupt so konfigurieren, dass er keine BPDUs vom Server mehr annimmt?

Im Handbuch steht dazu folgendes:

 

http://h20564.www2.hp.com/hpsc/doc/public/display?docId=mmr_kc-0118675&sp4ts.oid=5180892

 

Da gibt's einen Edge Port, Root Protection und Loop Protection. Kann einer von euch mir auf die Sprünge helfen?

Oder kann ich das vielleicht irgendwo in Windows so anpassen, dass die beiden Rechner mit aktivierter Netzwerkbrücke keine BPDUs mehr schicken? (wäre mir noch lieber)

bearbeitet 22. Juni 2015 von willy-goergen