71983
22.05.2009, aktualisiert um 12:33:37 Uhr
9501
12
0
Probleme mit 2 Switchen (ProCurve 1800-24G und ALL8895) in Serie
Starke Latenz-Zeiten auf Windows-Rechnern
Hallo,
eine bisher nur zu verdächtigende Person kam auf die Idee, zwei Switche, welche über je eine Leitung zu einem dritten Switch verfügen hintereinander zu hängen.
Vorher:
[ Überswitch ]--------[ ALL8895 ]
'----------[ ProCurve 1800-24G ]
Nachher:
[ Überswitch ]--------[ ALL8895 ]-------[ ProCurve 1800-24G ]
An sich sollte das, abgesehen von der widersinnigkeit, ja keine Probleme geben. Allerdings gab es auf allen Rechnern, die hinter dem HP Switch hingen starke Latenzzeiten bei bestimmten Operationen, wie zum Beispiel Text in eine Illustrator-Datei zu kopieren oder die Netzwerkeinstellungen zu öffnen, also auch bei lokalen Aktivitäten.
Gibt es dafür eine wissenschaftliche Erklärung?
Hallo,
eine bisher nur zu verdächtigende Person kam auf die Idee, zwei Switche, welche über je eine Leitung zu einem dritten Switch verfügen hintereinander zu hängen.
Vorher:
[ Überswitch ]--------[ ALL8895 ]
'----------[ ProCurve 1800-24G ]
Nachher:
[ Überswitch ]--------[ ALL8895 ]-------[ ProCurve 1800-24G ]
An sich sollte das, abgesehen von der widersinnigkeit, ja keine Probleme geben. Allerdings gab es auf allen Rechnern, die hinter dem HP Switch hingen starke Latenzzeiten bei bestimmten Operationen, wie zum Beispiel Text in eine Illustrator-Datei zu kopieren oder die Netzwerkeinstellungen zu öffnen, also auch bei lokalen Aktivitäten.
Gibt es dafür eine wissenschaftliche Erklärung?
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 116575
Url: https://administrator.de/forum/probleme-mit-2-switchen-procurve-1800-24g-und-all8895-in-serie-116575.html
Ausgedruckt am: 28.04.2025 um 13:04 Uhr
12 Kommentare
Neuester Kommentar
Was ist daran widersinnig ???
Aus Ethernet Designsicht ist das durchaus machbar wenn man einmal davon absieht das der gesamte Traffic vom Procurve Switch durch den ALL8895 durch muß um zum "Überswitch" (was auch immer das sein mag...?) zu kommen.
(Gibt es auch einen "Unterswitch" ??)
Kein besonders intelligendes Design und vermutlich von einem Anfänger designed, aber letztlich machbar.
Leider versäumst du uns zu beschreiben ob die Verbindung mit Glasfaser oder Kupfer gemacht wird so das wir hier mal wieder raten müssen
OK, raten wir mal das es Kupfer ist, dann gibt es 2 mögliche Fehlerszenarien:
a.) Die Autonegotiation (10/100/1000er und Duplex Erkennung) zwischen dem ProCurve und dem Allnet funktioniert nicht sauber.
Folglich kann es damit dann auf dem Link zu erheblichen Kollisionen kommen die die Performance drastisch in den Keller ziehen. (Kann natürlich auch zw. "Überswitch" und Allnet passieren oder auf beiden Links gleichzeitig ! )
Lösung: Beide Ports sowohl auf Procurve und Allnet Seite (ggf. auch Überswitch Seite ) auf feste, statische Port Parameter Speed und Duplex Mode einstellen !
Sind die Switche die du hast nicht managebar: Pech gehabt !
b.) Da Allnet zu den Taiwan Billigstheimern am alleruntersten Ende gehört ist es gut möglich das der Traffic vom Procurve ihn einfach überfordert.
Ggf. sollte ein Tausch (Überswitch)===(ProCurve)===(Allnet) das Problem dann etwas mildern da der ProCurve etwas performancefester ist !
Ggf. hilft das auch mit der Autonegotiation ?!
Fehlerhafte Kabel, Patchfelder, Dosen usw. wären auch ein möglicher Grund den du aber vermutlich wohl schon untersucht und ausgeschlossen hast....hoffentlich !!
Aus Ethernet Designsicht ist das durchaus machbar wenn man einmal davon absieht das der gesamte Traffic vom Procurve Switch durch den ALL8895 durch muß um zum "Überswitch" (was auch immer das sein mag...?) zu kommen.
(Gibt es auch einen "Unterswitch" ??)
Kein besonders intelligendes Design und vermutlich von einem Anfänger designed, aber letztlich machbar.
Leider versäumst du uns zu beschreiben ob die Verbindung mit Glasfaser oder Kupfer gemacht wird so das wir hier mal wieder raten müssen
OK, raten wir mal das es Kupfer ist, dann gibt es 2 mögliche Fehlerszenarien:
a.) Die Autonegotiation (10/100/1000er und Duplex Erkennung) zwischen dem ProCurve und dem Allnet funktioniert nicht sauber.
Folglich kann es damit dann auf dem Link zu erheblichen Kollisionen kommen die die Performance drastisch in den Keller ziehen. (Kann natürlich auch zw. "Überswitch" und Allnet passieren oder auf beiden Links gleichzeitig ! )
Lösung: Beide Ports sowohl auf Procurve und Allnet Seite (ggf. auch Überswitch Seite ) auf feste, statische Port Parameter Speed und Duplex Mode einstellen !
Sind die Switche die du hast nicht managebar: Pech gehabt !
b.) Da Allnet zu den Taiwan Billigstheimern am alleruntersten Ende gehört ist es gut möglich das der Traffic vom Procurve ihn einfach überfordert.
Ggf. sollte ein Tausch (Überswitch)===(ProCurve)===(Allnet) das Problem dann etwas mildern da der ProCurve etwas performancefester ist !
Ggf. hilft das auch mit der Autonegotiation ?!
Fehlerhafte Kabel, Patchfelder, Dosen usw. wären auch ein möglicher Grund den du aber vermutlich wohl schon untersucht und ausgeschlossen hast....hoffentlich !!
Also auf jeden Fall ist der "Überswitch" schonmal deutsch *fg* - das musste sein, bitte nicht falsch verstehen.
der 1800-24G ist ein Soft-Layer 2 Switch, also managebar.
Schau dir doch einfach mal an was die Traffic-Log an den Uplink-Ports so anzeigt.
Bei einem Funktionierenden sieht das ca. so aus:
Grüße
Max
der 1800-24G ist ein Soft-Layer 2 Switch, also managebar.
Schau dir doch einfach mal an was die Traffic-Log an den Uplink-Ports so anzeigt.
Bei einem Funktionierenden sieht das ca. so aus:
Grüße
Max
Raten macht doch Spass 
Also, @aqui die beiden Switches sind manageable. @redbeared ein bisschen genauer, was umgestellt wurde wär schon gut. Wer oder was ist der Überswitch? Ich nehme an, das die vorige Konfiguration mit einem Kabel vom ÜS zum procurve und mit einem Kabel vom ÜS zum Allnet geht. Hast Du die kabel kontrolliert? Wurde versehentlich ein Loop gebaut? Also vom ÜS zum Allnet zum Procurve und wieder zurück? Sind die Switche überhaupt gemanaged worden? in wie weit kannst Du experimentieren (ist ja Freitag/Brückentag).
Kontrollier als erstes mal, ob die Verkabelung von der zu verdächtigenden Person (Wie geht das? bei mir mache ich das oder einer meiner Kollegen, aber kein Ahnungsloser) richtig gesetzt wurde.
Gruss Chips
Also, @aqui die beiden Switches sind manageable. @redbeared ein bisschen genauer, was umgestellt wurde wär schon gut. Wer oder was ist der Überswitch? Ich nehme an, das die vorige Konfiguration mit einem Kabel vom ÜS zum procurve und mit einem Kabel vom ÜS zum Allnet geht. Hast Du die kabel kontrolliert? Wurde versehentlich ein Loop gebaut? Also vom ÜS zum Allnet zum Procurve und wieder zurück? Sind die Switche überhaupt gemanaged worden? in wie weit kannst Du experimentieren (ist ja Freitag/Brückentag).
Kontrollier als erstes mal, ob die Verkabelung von der zu verdächtigenden Person (Wie geht das? bei mir mache ich das oder einer meiner Kollegen, aber kein Ahnungsloser) richtig gesetzt wurde.
Gruss Chips
"Überswitch" habe ich den nur genannt, weil er Netzwerktopologisch über den anderen steht und offenbar nichts mit dem Problem zu tun hat. Die Leitungen sind in Ordnung, es scheint also an dem ALLNET-Gerät zu liegen, was folgende Beobachtung bestätigt:
Die ALLNET Kiste hängt nun hinter dem ProCurve Switch. Erstere versorgt nur ein paar Telefone mit POE und hängt nun nicht mehr im Pfad von den Client-Rechnern zum ÜS. Die Verbindung zwischen ALLNET und ProCurve habe ich beidseitig manuell auf 1000M FDX gestellt, das Problem bleibt dennoch bestehen, bis (und jetzt kommts) ich die ALLNET Kiste vom ProCurve trenne.
Das ALLNET Gerät scheint also die Client-Rechner auf irgendeine Art und Weise zu beeinflussen, trotzdem diese nichts miteinander zu schaffen haben sollten.
Die ALLNET Kiste hängt nun hinter dem ProCurve Switch. Erstere versorgt nur ein paar Telefone mit POE und hängt nun nicht mehr im Pfad von den Client-Rechnern zum ÜS. Die Verbindung zwischen ALLNET und ProCurve habe ich beidseitig manuell auf 1000M FDX gestellt, das Problem bleibt dennoch bestehen, bis (und jetzt kommts) ich die ALLNET Kiste vom ProCurve trenne.
Das ALLNET Gerät scheint also die Client-Rechner auf irgendeine Art und Weise zu beeinflussen, trotzdem diese nichts miteinander zu schaffen haben sollten.
Prüfe mal ob "Flow Control" ggf. eingeschaltet ist. Das solltest du wenn es inhomogen eingestellt ist entweder generell ausschalten oder einschalten.
Bei hetereogenen Netzen ist es besser du schaltest es komplett ab !
Prüfen solltest du auch ob generell Spanning Tree aktiviert ist.
Hat der ÜS Spanning Tree aktiviert solltest du das beim Procurve UND beim Allnet auch machen.
Kann so oder so nicht schaden um sicher Loops zu verhindern.
Bei hetereogenen Netzen ist es besser du schaltest es komplett ab !
Prüfen solltest du auch ob generell Spanning Tree aktiviert ist.
Hat der ÜS Spanning Tree aktiviert solltest du das beim Procurve UND beim Allnet auch machen.
Kann so oder so nicht schaden um sicher Loops zu verhindern.
Ich habe auf beiden Seiten "Flow Control" ausgeschaltet und versuchsweise auch mal auf 100 FDX heruntergeschaltet, was keine Verbesserung brachte.
Mir leuchtet inzwischen auch ein, was der große Vorteil ist, wenn man ALLNET und HP hintereinander hängt, nämlich, dass sich so das Port Trunking der beiden Leitungen zum ÜS nutzen lässt. Leider tritt das beschriebene Problem in jeder Versuchsanordnung auf, in der HP und ALLNET direkt zusammenhängen, sodass man die ALLNET Kiste nach wie vor direkt mit dem ÜS verbinden muss, damit es funktioniert.
Mir leuchtet inzwischen auch ein, was der große Vorteil ist, wenn man ALLNET und HP hintereinander hängt, nämlich, dass sich so das Port Trunking der beiden Leitungen zum ÜS nutzen lässt. Leider tritt das beschriebene Problem in jeder Versuchsanordnung auf, in der HP und ALLNET direkt zusammenhängen, sodass man die ALLNET Kiste nach wie vor direkt mit dem ÜS verbinden muss, damit es funktioniert.
Hi !
Ohjee über den Soho Switch geht der gesamte Traffic vom Procurve und den Überswitch (Bei dem Namen, bestimmt noch deutsche Wertarbeit) verschweigst Du uns ja
Anhand Deiner Aussage "Illustrator Dateien", gehe ich davon aus, dass ihr mit dem Netzwerk Geld verdienen wollt, richtig ?
Also den Allnet raus ! Und wehe, Du kaufst einen von Dlink, dann komm ich persönlich vorbei und nehme Dir Deinen Job weg (nicht wirklich... Bist nicht wirklich zu beneiden)
Nix für ungut, hast bestimmt schon Ärger genug. Ich habe auch schon mal Sohoware installiert aber nur einmal und Du weisst ja, im Einkauf sitzen immer die Unschuldigen
mrtux
Zitat von @71983:
[ Überswitch ]--------[ ALL8895 ]-------[ ProCurve 1800-24G ]
[ Überswitch ]--------[ ALL8895 ]-------[ ProCurve 1800-24G ]
Ohjee über den Soho Switch geht der gesamte Traffic vom Procurve und den Überswitch (Bei dem Namen, bestimmt noch deutsche Wertarbeit) verschweigst Du uns ja
Anhand Deiner Aussage "Illustrator Dateien", gehe ich davon aus, dass ihr mit dem Netzwerk Geld verdienen wollt, richtig ?
Also den Allnet raus ! Und wehe, Du kaufst einen von Dlink, dann komm ich persönlich vorbei und nehme Dir Deinen Job weg (nicht wirklich... Bist nicht wirklich zu beneiden)
Nix für ungut, hast bestimmt schon Ärger genug. Ich habe auch schon mal Sohoware installiert aber nur einmal und Du weisst ja, im Einkauf sitzen immer die Unschuldigen
mrtux
Ha...der mit dem D-Link ist gut (...und auch richtig !!!)
Die Aussage Port Trunking oben ist missverständlich !!!
Wie meinst du das ??? Du trunkst auf dem Link zw. dem ÜS und dem folgenden Switch ???
Bedenke wenn du zwischen 2 unterschieldichen Herstellern trunkst solltest du immer 802.3ad als Standard benutzen keine statischen Trunks !!
Das die Trunkkonfig auf BEIDEN Seiten des Links pro Switch eingestellt werden muss sollte dir klar sein !
Spanning Tree ist dann so oder so Pflicht !! Gerade wenn die angeschlossenen VoIP Telefone einen integrierten Switch haben !!
Die Aussage Port Trunking oben ist missverständlich !!!
Wie meinst du das ??? Du trunkst auf dem Link zw. dem ÜS und dem folgenden Switch ???
Bedenke wenn du zwischen 2 unterschieldichen Herstellern trunkst solltest du immer 802.3ad als Standard benutzen keine statischen Trunks !!
Das die Trunkkonfig auf BEIDEN Seiten des Links pro Switch eingestellt werden muss sollte dir klar sein !
Spanning Tree ist dann so oder so Pflicht !! Gerade wenn die angeschlossenen VoIP Telefone einen integrierten Switch haben !!
Der 1800-24G ist zu billig, als dass er STP können würde.
Dazu sollte an Kupfer-Ports immer eine Autoerkennung stattfinden, weil mindestens der HP Auto MDI-X kann.
Was sagt denn nun der Traffic-Monitor des HP?
Ich sehe momentan ein Problem mit den IP-Telefonen.
Ich könnte mir vorstellen, dass der Allnet Switch QoS in einer derart komischen Weise anwendet, dass es den anderen Traffic benachteiligt.
Grüße
Max
Dazu sollte an Kupfer-Ports immer eine Autoerkennung stattfinden, weil mindestens der HP Auto MDI-X kann.
Was sagt denn nun der Traffic-Monitor des HP?
Ich sehe momentan ein Problem mit den IP-Telefonen.
Ich könnte mir vorstellen, dass der Allnet Switch QoS in einer derart komischen Weise anwendet, dass es den anderen Traffic benachteiligt.
Grüße
Max
Das war es noch nicht, ich bin nur grad etwas bisi.
Beim "Überswitch", um das Geheimnis mal zu lüften, handelt es sich im Übrigen um ein Netgear GS724T.
Die aktuelle Lage ist zur Zeit diese:
Die Verzögerungen haben offenbar doch nichts mit dem ALLNET Gerät zu tun, auch wenn es zunächst so aussah. Ob sie evtl. mit dem ProCurve zusammenhängen, muss ich noch herausfinden, könnte aber sein. Das Problem besteht zur Zeit im gesamten Netz, also nicht nur an den Rechnern hinter dem ProCurve.
Auftreten tun die Latenzzeiten vor allem beim Kopieren von Text (zum Beispiel aus dem Browser) in ein anderes Programm.
Mehr kann ich zur Zeit leider nicht sagen, da ich nicht jeden Tag vor Ort bin. Über Vorschläge dahingehend, wo ich noch nachsehen könnte wäre ich sehr dankbar.
Beim "Überswitch", um das Geheimnis mal zu lüften, handelt es sich im Übrigen um ein Netgear GS724T.
Die aktuelle Lage ist zur Zeit diese:
Die Verzögerungen haben offenbar doch nichts mit dem ALLNET Gerät zu tun, auch wenn es zunächst so aussah. Ob sie evtl. mit dem ProCurve zusammenhängen, muss ich noch herausfinden, könnte aber sein. Das Problem besteht zur Zeit im gesamten Netz, also nicht nur an den Rechnern hinter dem ProCurve.
Auftreten tun die Latenzzeiten vor allem beim Kopieren von Text (zum Beispiel aus dem Browser) in ein anderes Programm.
Mehr kann ich zur Zeit leider nicht sagen, da ich nicht jeden Tag vor Ort bin. Über Vorschläge dahingehend, wo ich noch nachsehen könnte wäre ich sehr dankbar.
Das Problem ist gelöst, anscheinend lag es an einem der NICs. Was genau das Problem war, konnte ich leder nicht nachvollziehen.
