Zum Inhalt wechseln


Foto

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


  • Bitte melde dich an um zu Antworten
198 Antworten in diesem Thema

#16 MurdocX

MurdocX

    Board Veteran

  • 543 Beiträge

 

Geschrieben 12. Juni 2015 - 09:34

Auf den Servern ist soweit nichts zu sehen, was in irgendeiner Form auf Netzwerkprobleme hindeutet.

 

Normal ist mal nicht, dass du so oft Verbindungsabbrüche auf deinem Switch hast (-; (UP/DOWN der Ports).

Irgendwo muss man mal anfangen und da könntest du starten.


Mit freundlicher Unterstützung
Jan


#17 NorbertFe

NorbertFe

    Expert Member

  • 30.595 Beiträge

 

Geschrieben 12. Juni 2015 - 09:42

Nicht ganz richtig, aber  auch nicht ganz falsch:
 
Bei einem Knick verändern sich die elektrischen Eigenschaften des Kabels. Z.B. die Dämpfung und das Übersprechen. Bei den  hohen Frequenzen kann das durchaus relevant sein.


Weiß ich doch. War durch den Smiley nicht ausreichend erkennbar? ;)

Von Willy ist jetzt mindestens der 3. Thread zu Netzwerkfehlern. Darüber darf er mal nachdenken. Wie war  das noch mit der SQL-Anwendung?
Ich tippe aus der Ferne immer noch auf einen Loop o.ä.


... ;)

Make something i***-proof and they will build a better i***.


#18 MHenning

MHenning

    Newbie

  • 91 Beiträge

 

Geschrieben 12. Juni 2015 - 09:46

Hi Willy,

 

Zitat:

Auf meinem Rechner tritt immer wieder ein Problemen beim ziehen von GPOs auf. Mal geht's... Die letzte Zeit desöfteren nicht. Ob das auch mit dem Problem zusammen hängt?

 

Ich denke du solltest auf den switchen das STP Protokoll abschalten. Natürlich nur wenn Du vorher definitiv gecheckt hast ob kein Loop im Netzwerk ist.

Denn das mit den GPOs ziehen kenne auch, und es war das STP Protokoll was standardmäßig aktiviert war.

Ich habs überall dort deaktiviert wo ich es nicht brauche, schon schnurrte das ganze wieder.

in deinem Screenshot steht doch schon was von MSTP, und wenn Du nicht gerade VLAN-übergreifend was machen willst dann schalte es ab.

(http://de.wikipedia....g_Tree_Protocol)

 

Fakt ist, das STP Protokoll-Problem wurde immer stärker umso mehr Switche dazu kamen.

Als ich das abgeschaltet hatte ging das ganze Netzwerk spürbar besser.

 

Probleme waren zB.

- GPOs wurden nicht gezogen weil Netzwerk zu lahm war.

- SAP Verbindungsabbrüche sporadisch

- Zero-Clients haben mehr als 45 Sekunden gebraucht um eine IP Adresse zu bekommen

 

Nach unserer Änderung ohne STP Protokoll gibt es diese Probleme einfach nicht mehr.

 

Gruß Martin


Nur tote Fische Schwimmen mit dem Strom !


#19 DocData

DocData

    Board Veteran

  • 1.270 Beiträge

 

Geschrieben 12. Juni 2015 - 10:05

Ich denke du solltest auf den switchen das STP Protokoll abschalten. Natürlich nur wenn Du vorher definitiv gecheckt hast ob kein Loop im Netzwerk ist.


Schlechtester Rat den man hier geben kann. Wie wäre es damit, STP mal zu konfigurieren? Davon ab sollte man STP heute gar nicht mehr nutzen, sondern seit über 10 Jahren RSTP nutzen. Bei RSTP werden Ports, an denen Endgeräte hängen (sog. Edge-Ports) nicht mehr berücksichtigt. Das führt u.a. dazu, dass der Port sofort, oder innerhalb kurzer Zeit online ist. Das von dir beschriebene Verhalten tritt dann nicht auf.

In deinem Screenshot steht doch schon was von MSTP, und wenn Du nicht gerade VLAN-übergreifend was machen willst dann schalte es ab.
(http://de.wikipedia....g_Tree_Protocol)


Auch wieder so eine Pauschalaussagedie von wenig Knowhow zeugt.

Fakt ist, das STP Protokoll-Problem wurde immer stärker umso mehr Switche dazu kamen.
Als ich das abgeschaltet hatte ging das ganze Netzwerk spürbar besser.


Du solltest auch nicht irgendwas einfach aktivieren, sondern es aktivieren und konfigurieren. Am besten geht das, wenn man die Sache um die es geht auch verstanden hat.
  • NorbertFe gefällt das

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#20 MHenning

MHenning

    Newbie

  • 91 Beiträge

 

Geschrieben 12. Juni 2015 - 10:33

Hi DocData,

 

hat dein Beitrag jetzt zur Lösung beigetragen oder ist die nur gegen meine Aussagen?

Muss ich ja wissen.

 

Wenn ich gezielt auf einem Switch wissentlich das STP Protokoll abschalte (in der Config heißt es bei mir auch RSTP oder MSTP)  um ein Problem in den Griff zu bekommen dann ist das falsch?

Ich hab mir dafür sogar externe Unterstüzung geholt. Und ich hab mich vorher natürlich intensiv damit auseinander gesetzt, um von vornherein keine Fehler einzubauen.

 

Fakt ist aber, solanger der TO keine Netzwerkübersicht, so einfach sie auch sein kann,einstellt, können wir hier eh nicht richtig helfen.

Also beruhige Dich, heute ist Freitag, das Wochenende ist nah.

 

Mehr als eine Pauschalaussage kann man hier eh nicht abgeben,weil wir das Netz dort beim TO nicht einsehen und genau nachvollziehen wie das aufgebaut ist.

 

 

Weitermachen :-)

 

Gruß martin


Bearbeitet von MHenning, 12. Juni 2015 - 10:34.

Nur tote Fische Schwimmen mit dem Strom !


#21 DocData

DocData

    Board Veteran

  • 1.270 Beiträge

 

Geschrieben 12. Juni 2015 - 11:12

Wenn ich gezielt auf einem Switch wissentlich das STP Protokoll abschalte (in der Config heißt es bei mir auch RSTP oder MSTP)  um ein Problem in den Griff zu bekommen dann ist das falsch?


Ja. Das klassische STP schaltet einen Port erst nach 30 Sekunden für den gesamten Verkehr frei. Davor ist der Port für sämtlichen Traffic, außer BPDU, gesperrt. Da ein Rechner aber i.d.R. schneller bootet versucht er zu einem Zeitpunkt, wo kein Netzwerkverkehr möglich ist, z.B. einen DC zu erreichen. Deswegen RSTP. Deswegen Konfiguration von Edge Ports.

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#22 MHenning

MHenning

    Newbie

  • 91 Beiträge

 

Geschrieben 12. Juni 2015 - 11:29

Hi Doc,

 

die Frage ist jetzt natürlich ob unser Offtopicgeraschel dem TO hilft sein Problem in den Griff zu bekommen?

 

Gruß Martin


Nur tote Fische Schwimmen mit dem Strom !


#23 DocData

DocData

    Board Veteran

  • 1.270 Beiträge

 

Geschrieben 12. Juni 2015 - 11:39

Warum? Der soll endlich jemanden holen, der sich damit auskennt. Aber das wurde ja schon mehrfach gesagt.

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#24 lefg

lefg

    Expert Member

  • 20.474 Beiträge

 

Geschrieben 12. Juni 2015 - 12:32

Warum? Der soll endlich jemanden holen, der sich damit auskennt. Aber das wurde ja schon mehrfach gesagt.

 

Hallo werter DocData,

 

überlasse das Holen sollen nur dem Willy selbst! Der braucht dazu keine so massive Anregung hier.


Das Messbare messen, das Nichtmessbare messbar machen. Galilei.

 

Diskutiere nicht mit ***en, denn sie ziehen dich auf ihr Niveau und schlagen dich dort mit Erfahrung! (Hab ich bei Tom abgeguckt)

 

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität. (Hab ich bei Daniel abgeguckt) https://de.wikipedia...rgo_propter_hoc

 

Absolutistischer“ Geschäftsführungs-Dogmatismus, der jedwede Empirie aus der „Werkstatt“ schlichtweg ignoriert , führt eben zumeist früher als später ….  (Hab ich von Klabautermann)


#25 willy-goergen

willy-goergen

    Board Veteran

  • 480 Beiträge

 

Geschrieben 12. Juni 2015 - 12:37

Anbei eine Übersicht über das Netzwerk. Ich hoffe, es hilft etwas weiter.

 

[attachment=8189:Netzwerkübersicht.png]

 

In den Verteilern sind neben den Switches Patchfelder, über die das Netzwerk/Telefon weiter verteilt wird.

 

EDIT: Ich habe gerade probiert, das Problem weiter einzugrenzen.

In der Hauptverteilung habe ich, nachdem keiner mehr da ist, alles vom Switch abgesteckt, was nicht gebraucht wird.
Davor war z.B. das ERP-System wieder endlos am kreiseln.

 

Im Moment hängen nur noch die Server, mein Rechner, ein Netzwerkdrucker, die Telefonanlage und die beiden Zwischenverteilungen daran.

 

Die Zwischenverteilung 1 hängt mit in einer Leitung, wo ich sie nicht vermutet habe und wo sie eigentlich nicht sein dürfte. Da wurden mehrere Dinge auf einmal in eine Leitung reingetüdelt. 

 

Das ewige kreiseln im ERP-System ist jetzt jedenfalls weg, ohne dass ich den Switch neu gestartet habe. 

Evtl. hat zahni mit seiner Vermutung recht. Der Switch scheint ok sein. In der ganzen Verkabelung liegt möglicherweise irgendwo ein Fehler.

 

Da muss eine Fachfirma ran, wenn mehr dran zu machen ist

 

EDIT²: Die eine Leitung (Verbindung Hauptverteilung zu Zwischenverteilung 1), die ich da gefunden habe, sehe ich mir nochmal genauer an. Es ist nicht ganz unwahrscheinlich, dass es da ein Problem gibt.

 

 

Warum? Der soll endlich jemanden holen, der sich damit auskennt. Aber das wurde ja schon mehrfach gesagt.

 

 

Du brauchst nicht zu denken, dass mir das immer Spaß macht. Letztlich hast du dich meine ich dazu in keinem Thema geäußert, wenn ich mich recht erinnere. Nimm dir ein Beispiel an Norbert. Der gibt meistens gute Ratschläge, auf seine eigene Art...


Bearbeitet von willy-goergen, 12. Juni 2015 - 18:42.


#26 willy-goergen

willy-goergen

    Board Veteran

  • 480 Beiträge

 

Geschrieben 13. Juni 2015 - 09:30

Vielleicht interessiert es hier ja auch jemanden. Ich bin auf eine recht interessante Sache gestoßen, die evtl. sogar die Lösung des Problems darstellt.

Achtung... das wird recht viel zum Lesen!

 

Ich hatte ja geschrieben, dass die Switches damals beim Einbau überhaupt nicht konfiguriert wurden.

Daneben haben wir hier festgestellt, dass es diverse UP/DOWNs an zufälligen Ports in sämtlichen Bereichen der Firma gibt.

 

Im Weiteren habe ich folgende Fehlermeldung des Switches "Hauptverteilung Verwaltung" betrachtet.

 

[attachment=8193:syslog_hauptverteilung.png]

 

Man sieht wieder ein UP/DOWN. Ich habe es markiert. Dieses Mal war an dem Port, an dem der Emailserver hängt kurz die Verbindung weg. Sehr viel mehr, sieht man leider nicht.

Dieses Ereignis habe ich hergenommen, und auf dem Emailserver im Eventlog nach einem Verbindungsabbruch gesucht.

 

[attachment=8194:eventlog_server2012.png]

 

Tatsächlich gibt es da einen Eintrag, der zeitlich (fast ganz genau) zu dem passt, was im Syslog vom Switch zu sehen ist. Man weiß zwar jetzt, dass es einen Verbindungsabbruch gab. Aber warum irgendwie immer noch nicht so recht.

Nachdem ich mich ein bisschen mit dem Webinterface vom Switch beschäftigt hatte, wusste ich, wo ich die ausführlichen Diagnoseinformationen abrufen kann. Die gaben folgendes dazu her:

Port GigabitEthernet1/0/1
   Role change   : Desi->Root
   Time          : 2015/06/12 15:58:58
   Port priority : 32768.00ff-3169-ef74 0 32768.d07e-28d9-e9e4 0
                   32768.00ff-3169-ef74 128.0

 Port GigabitEthernet1/0/1
   Role change   : Root->Desi (Aged)
   Time          : 2015/06/12 15:58:57
   Port priority : 32768.00ff-3169-ef74 0 32768.d07e-28d9-e9e4 0
                   32768.00ff-3169-ef74 128.0

Das passt zeitlich (fast) ganz genau zu dem, was im Webinterface vom Switch und im Eventlog vom Server zu sehen ist.

Ab da wurde mir dann so langsam klar, woran es liegen könnte.

 

Der Fehler passiert, weil beim Einbau der Switches keine Root-Bridge konfiguriert wurde und STP aktiviert war. Ich habe die Konfiguration von STP in der Hauptverteilung entsprechend angepasst und aus dem Switch die Root-Bridge gemacht. Seitdem gibt an der Root-Bridge keine Root-Ports mehr und die anderen beiden Zwischenverteilungen wissen genau, über welchen Port sie die Root-Bridge erreichen können. Die Performanceprobleme im Netzwerk sind im Moment auch komplett weg, ebenso wie die ständigen UP/DOWNs im Syslog der Switches. Alles läuft schön stabil schnell... Mal abwarten, wie das dann im laufenden Betrieb aussieht.

 

@Martin: Nachdem ich mich ein bisschen damit auseinander gesetzt habe, halte ich es auch für ganz schlecht STP komplett zu deaktivieren. Du könntest probieren es anzupassen, wenn damit Probleme auftreten. Dazu hab ich auch einen ganz interessanten Artikel im Netz gefunden. Dein Tipp ging aber schon die richtige Richtung.

 

http://www.networkwo...e-mistakes.html

 

Irgendwie frage ich mich nur, welche "Fachfirma" so einen Müll eingebaut hat und welcher ..... von Vorgänger sowas einfach ignoriert. Leider hat meine persönliche Neugierde, was solche Dinge betrifft, mal wieder gesiegt und ich hab mich selbst damit auseinander gesetzt.  :shock:


Bearbeitet von willy-goergen, 13. Juni 2015 - 09:54.


#27 DocData

DocData

    Board Veteran

  • 1.270 Beiträge

 

Geschrieben 13. Juni 2015 - 10:39

Wenn alle Switches die gleiche Bridge Prio haben, dann wird in einem bestimmten Verfahren eine Root Bridge ermittelt. Normalerweise sollte diese im Betrieb nicht wechseln, kann aber vorkommen wenn sich Änderungen am Netzwerk ergeben. Daher sollte IMMER, wirklich IMMER, wenn R/MSTP aktiviert wird, ein Switch als Root Bridge konfiguriert werden. Dies geschieht über die Anpassung der Bridge Priorität.

Diesen Müll veranstalten leider viele "Fachfirmen", da viele "Fachfirmen", gerade kleine Unternehmen, oft nicht verstanden haben was sie da eigentlich tun.

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#28 lefg

lefg

    Expert Member

  • 20.474 Beiträge

 

Geschrieben 13. Juni 2015 - 10:54

Kameraden,

 

ihr könnt doch nicht mit Sicherheit wissen, wer es wirklich war oder nicht. :)


Bearbeitet von lefg, 13. Juni 2015 - 10:55.

Das Messbare messen, das Nichtmessbare messbar machen. Galilei.

 

Diskutiere nicht mit ***en, denn sie ziehen dich auf ihr Niveau und schlagen dich dort mit Erfahrung! (Hab ich bei Tom abgeguckt)

 

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität. (Hab ich bei Daniel abgeguckt) https://de.wikipedia...rgo_propter_hoc

 

Absolutistischer“ Geschäftsführungs-Dogmatismus, der jedwede Empirie aus der „Werkstatt“ schlichtweg ignoriert , führt eben zumeist früher als später ….  (Hab ich von Klabautermann)


#29 willy-goergen

willy-goergen

    Board Veteran

  • 480 Beiträge

 

Geschrieben 13. Juni 2015 - 12:38

Kameraden,

 

ihr könnt doch nicht mit Sicherheit wissen, wer es wirklich war oder nicht. :)

 

Das wird nicht schwer. Ich geh am Montag in die Buchhaltung und suche mir die entsprechenden Rechnungen dazu heraus. Wer auch immer das verbrochen hat, wird für mich in Zukunft, wenn überhaupt, maximal noch einen Rechner aufsetzen dürfen.

 

Bevor das passiert, ist aber erst mal abzuwarten, ob das Netzwerkproblem damit überhaupt gelöst ist. ;)

 

Btw.... ich entwickle gerade eine Abneigung gegenüber HP-Switches mit Webinterface.

Während meines Studiums hab ich Cisco-Switches per CLI programmiert. Die waren mir wesentlich lieber gewesen.

 

Ich denke mit CLI hätte ich eher eine Rückmeldung erhalten, was genau nicht passt, anstatt in irgendwelchen verschachtelten Browsermenüs suchen zu müssen.


Bearbeitet von willy-goergen, 13. Juni 2015 - 13:06.


#30 DocData

DocData

    Board Veteran

  • 1.270 Beiträge

 

Geschrieben 13. Juni 2015 - 13:21

Während meines Studiums hab ich Cisco-Switches per CLI programmiert. Die waren mir wesentlich lieber gewesen.


Ein paar Befehle via CLI einzugeben macht aus jemandem noch lange keinen Netzwerk Experten. Ob du nun mit einer Web GUI oder einem CLI hantiert hättest, hätte deine Problemlösung in keinster Weise vereinfacht.

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...