52
NVDHS - SESSION 002 - EPISODE 01 - Patchkabel - Das Widerstand-Desaster!
Moin Zusammen,
mit diesem Beitrag, möchte ich ein riesiges Problem ansprechen, welches buchstäblich jeden von euch betrifft!
Wie es der Titel schon etwas verrät, geht es hierbei um ein in der IT absolut alltägliches Produkt, nämlich das Patchkabel.
Nun wird der eine oder anderen bestimmt denken, „na ja, was kann mit einem simplen Patchkabel schon grossartig nicht stimmen“ und ja, so habe ich bis vor kurzem auch gedacht. Ich verspreche euch jedoch, dass ihr nach dem Lesen dieses Beitrags, eure Patchkabel ganz anders betrachten werdet. ๐
Bevor ich jedoch ins Detail gehe, möchte ich zuerst ein paar wichtige Grundlagen der Ethernet -Verkabelung kurz durchkauen.
Mitunter das Wichtigste ist beim Ethernet die Gesamtlänge eines Channels, sprich die komplette Kabelverbindung zwischen zwei aktiven Ethernet Komponenten, die in Summe nicht länger als 100 Meter sein sollte.
Die folgende Doku von Fluke erklärt übrigens ganz gut was ein Channel bedeutet.
https://www.flukenetworks.com/knowledge-base/dsx-cableanalyzer-series/ch ...
Und damit ein solcher Ethernet Channel sauber läuft, muss dieser gemäss mitunter ISO/IEC 11801, diverseste Vorgaben erfüllen.
So darf z.B. der Schleifenwiderstand der vier Aderpaare einer Ethernet-Verbindung und zwar über den gesamten Channel hinweg, 25 Ohm nicht überschreiten.
Wenn der Channel POE+ oder gar 4PPOE tauglich sein sollte, dann darf der Schleifenwiderstand, sogar nur max. 12,5 Ohm betragen!
Zudem darf der Widerstand der einzelnen Adern eines Aderpaares untereinander nicht mehr als um 0,2 Ohm abweichen (PAIR UBL).
Ausserdem sollten die Schleifenwiderstände der vier Aderpaare, untereinander ebenfalls nicht um mehr als 0,2 Ohm abweichen (P2P UBL).
Und wie gesagt, die oberen Vorgaben gelten für den gesamten Channel!
Die Widerstandanforderungen werden aktuell zwar immer häufiger in Verbindung mit POE genannt,
in Wahrheit wurden diese jedoch schon am 23.April 2001 in der „ANSI/TIA/EIA-568-B.2“ Norm und zwar ganz unabhängig vom POE definiert!
Abgesehen von den Vorgaben für die Widerstände, gibt es je nach Kategorie (CAT 5E/6/6A), natürlich noch duzende andere Kriterien, die ein Ethernet-Channel erfüllen muss damit er auch die versprochene Bandbreite liefert.
In diesem Beitrag möchte ich jedoch aussliesslich auf den riesigen Murks bei den Widerständen eingehen.
Und zwar haben wir in den letzten Monaten bei diversen Kunden deren Netzwerkverkabelung, zum Teil nur stichprobenweise, zum Teil aber auch komplett reklassifiziert. Das Ergebnis war bei so gut wie allen Messungen mehr als ernüchternd. Denn so gut wie kein Channel, von denen die meisten eigentlich CAT 6A erfüllen sollten, hat vom Stand die CAT5E Anforderungen bestanden. ๐ฌ
Und mal abgesehen von solchem Murks, den ich in dem folgenden Artikel …
NVDHS - SESSION 001 - Installation Netzwerkdosen - So bitte nicht!
… schon beschrieben habe, haben sich die Patchkabel bei den entsprechenden Kunden, als die viel grössere Fehlerquelle herausgestellt. ๐ญ
Folgend ein paar Beispiele von den Schleifenwiederständen einiger lediglich !! ein Meter !! langer Patchkabel.
Ja, ich weiss … ๐ฑ … und dass bei einer Patchkabellänge von nur einem Meter. ๐
Dabei sind das jetzt garantiert nicht die schlimmsten Beispiele, sondern eher das Mittelfeld.
Und nein, wir sprechen hier leider auch nicht über unglückliche Ausreisser.
Bei einem unserer Kunden, haben wir bereits einen grossen Teil seiner Verkabelung durchgetestet, bei der hunderte von Patchkabeln von bestimmt einem duzenden Hersteller verwendet wurden.
Und von diesen hunderten von Patchkabel, mussten leider ca. 95% getauscht werden, damit unser DSX die entsprechenden Channels, als lediglich !!! CAT5E !!! tauglich durchgelassen hat. ๐ญ
Folgend die Ausbaute an defekten Patchkabeln vom nur dem letzten WE.
Nun kommt das Derbste, einige diese Patchkabel sind noch keine 3 Monate alt gewesen. ๐คข๐คฎ
Und ja, einige von diesen Patchkabeln stammen definitiv aus dubiosen Quellen, einige waren wiederum gute Markenartikel. ๐
Was mich persönlich an dem Ganzen extremst stört, ist die schiere Masse der defekten Patchkabel.
Aber vor allem fuchst mich die Tatsache, dass selbst neue Patchkabel, schon nach Monaten und ohne besondere Belastung, den Geist aufzugeben scheinen. ๐คฎ
Ich kann nach den Erfahrungen der letzten Monate, daher jedem der ein grösseres Netz betreut nur empfehlen, seine Ethernet-Channels mal mit einem anständigen LAN Qualifier alla Fluke DSX 8000, durchzutesten.
Übrigens, um mal schnell zu prüfen ob das eigene Netzwerk von diesem Problem betroffen ist, hilft schon ein Blick auf die Tx und Rx Fehlerraten, der entsprechenden Switche.
Sollten die Fehlerraten bei dem einen oder anderen Port extrem durch die Decke gehen, so ist das ein Anzeichen dafür, das mit der entsprechenden Verkabelung dahinter, irgendetwas nicht stimmen könnte. ๐
In den nächsten Episoden dieser Session, werde ich mitunter etwas detailierter auf das eine oder andere nagelneue Patchkabel eingehen, welches ich schon testweise z.B. über Amazon gekauft habe. ๐ฌ
Aber auch auf die Markenware ... natürlich auch die aus dem Ländle aber auch eine sehr bemerkenswerte aus der Schweiz, werde ich auch noch etwas genauer eingehen.
Ferner werde ich versuchen den Grund für das vorzeitige Altern noch genauer herauszufuchsen.
Beste Grüsse aus BaWü
Alex
P.S. Einen DSX 8000 kann man Wochenweise z.B. bei der DMN mieten.
https://www.dmn-solutions.com/
mit diesem Beitrag, möchte ich ein riesiges Problem ansprechen, welches buchstäblich jeden von euch betrifft!
Wie es der Titel schon etwas verrät, geht es hierbei um ein in der IT absolut alltägliches Produkt, nämlich das Patchkabel.
Nun wird der eine oder anderen bestimmt denken, „na ja, was kann mit einem simplen Patchkabel schon grossartig nicht stimmen“ und ja, so habe ich bis vor kurzem auch gedacht. Ich verspreche euch jedoch, dass ihr nach dem Lesen dieses Beitrags, eure Patchkabel ganz anders betrachten werdet. ๐
Bevor ich jedoch ins Detail gehe, möchte ich zuerst ein paar wichtige Grundlagen der Ethernet -Verkabelung kurz durchkauen.
Mitunter das Wichtigste ist beim Ethernet die Gesamtlänge eines Channels, sprich die komplette Kabelverbindung zwischen zwei aktiven Ethernet Komponenten, die in Summe nicht länger als 100 Meter sein sollte.
Die folgende Doku von Fluke erklärt übrigens ganz gut was ein Channel bedeutet.
https://www.flukenetworks.com/knowledge-base/dsx-cableanalyzer-series/ch ...
Und damit ein solcher Ethernet Channel sauber läuft, muss dieser gemäss mitunter ISO/IEC 11801, diverseste Vorgaben erfüllen.
So darf z.B. der Schleifenwiderstand der vier Aderpaare einer Ethernet-Verbindung und zwar über den gesamten Channel hinweg, 25 Ohm nicht überschreiten.
Wenn der Channel POE+ oder gar 4PPOE tauglich sein sollte, dann darf der Schleifenwiderstand, sogar nur max. 12,5 Ohm betragen!
Zudem darf der Widerstand der einzelnen Adern eines Aderpaares untereinander nicht mehr als um 0,2 Ohm abweichen (PAIR UBL).
Ausserdem sollten die Schleifenwiderstände der vier Aderpaare, untereinander ebenfalls nicht um mehr als 0,2 Ohm abweichen (P2P UBL).
Und wie gesagt, die oberen Vorgaben gelten für den gesamten Channel!
Die Widerstandanforderungen werden aktuell zwar immer häufiger in Verbindung mit POE genannt,
in Wahrheit wurden diese jedoch schon am 23.April 2001 in der „ANSI/TIA/EIA-568-B.2“ Norm und zwar ganz unabhängig vom POE definiert!
Abgesehen von den Vorgaben für die Widerstände, gibt es je nach Kategorie (CAT 5E/6/6A), natürlich noch duzende andere Kriterien, die ein Ethernet-Channel erfüllen muss damit er auch die versprochene Bandbreite liefert.
In diesem Beitrag möchte ich jedoch aussliesslich auf den riesigen Murks bei den Widerständen eingehen.
Und zwar haben wir in den letzten Monaten bei diversen Kunden deren Netzwerkverkabelung, zum Teil nur stichprobenweise, zum Teil aber auch komplett reklassifiziert. Das Ergebnis war bei so gut wie allen Messungen mehr als ernüchternd. Denn so gut wie kein Channel, von denen die meisten eigentlich CAT 6A erfüllen sollten, hat vom Stand die CAT5E Anforderungen bestanden. ๐ฌ
Und mal abgesehen von solchem Murks, den ich in dem folgenden Artikel …
NVDHS - SESSION 001 - Installation Netzwerkdosen - So bitte nicht!
… schon beschrieben habe, haben sich die Patchkabel bei den entsprechenden Kunden, als die viel grössere Fehlerquelle herausgestellt. ๐ญ
Folgend ein paar Beispiele von den Schleifenwiederständen einiger lediglich !! ein Meter !! langer Patchkabel.
Ja, ich weiss … ๐ฑ … und dass bei einer Patchkabellänge von nur einem Meter. ๐
Dabei sind das jetzt garantiert nicht die schlimmsten Beispiele, sondern eher das Mittelfeld.
Und nein, wir sprechen hier leider auch nicht über unglückliche Ausreisser.
Bei einem unserer Kunden, haben wir bereits einen grossen Teil seiner Verkabelung durchgetestet, bei der hunderte von Patchkabeln von bestimmt einem duzenden Hersteller verwendet wurden.
Und von diesen hunderten von Patchkabel, mussten leider ca. 95% getauscht werden, damit unser DSX die entsprechenden Channels, als lediglich !!! CAT5E !!! tauglich durchgelassen hat. ๐ญ
Folgend die Ausbaute an defekten Patchkabeln vom nur dem letzten WE.
Nun kommt das Derbste, einige diese Patchkabel sind noch keine 3 Monate alt gewesen. ๐คข๐คฎ
Und ja, einige von diesen Patchkabeln stammen definitiv aus dubiosen Quellen, einige waren wiederum gute Markenartikel. ๐
Was mich persönlich an dem Ganzen extremst stört, ist die schiere Masse der defekten Patchkabel.
Aber vor allem fuchst mich die Tatsache, dass selbst neue Patchkabel, schon nach Monaten und ohne besondere Belastung, den Geist aufzugeben scheinen. ๐คฎ
Ich kann nach den Erfahrungen der letzten Monate, daher jedem der ein grösseres Netz betreut nur empfehlen, seine Ethernet-Channels mal mit einem anständigen LAN Qualifier alla Fluke DSX 8000, durchzutesten.
Übrigens, um mal schnell zu prüfen ob das eigene Netzwerk von diesem Problem betroffen ist, hilft schon ein Blick auf die Tx und Rx Fehlerraten, der entsprechenden Switche.
Sollten die Fehlerraten bei dem einen oder anderen Port extrem durch die Decke gehen, so ist das ein Anzeichen dafür, das mit der entsprechenden Verkabelung dahinter, irgendetwas nicht stimmen könnte. ๐
In den nächsten Episoden dieser Session, werde ich mitunter etwas detailierter auf das eine oder andere nagelneue Patchkabel eingehen, welches ich schon testweise z.B. über Amazon gekauft habe. ๐ฌ
Aber auch auf die Markenware ... natürlich auch die aus dem Ländle aber auch eine sehr bemerkenswerte aus der Schweiz, werde ich auch noch etwas genauer eingehen.
Ferner werde ich versuchen den Grund für das vorzeitige Altern noch genauer herauszufuchsen.
Beste Grüsse aus BaWü
Alex
P.S. Einen DSX 8000 kann man Wochenweise z.B. bei der DMN mieten.
https://www.dmn-solutions.com/
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6793714550
Url: https://administrator.de/contentid/6793714550
Printed on: April 27, 2024 at 11:04 o'clock
52 Comments
Latest comment
Das erinnert mich gleich wieder bei Aliexpress neue Patchkabel zu bestellen, auch die Ladekabel und Netzteile aus China sind "super". Und alles zu brandheißen Preisen.
Wir kaufen bei losen Kabeln ausschließlich Easylan und bei den Verlegekabeln für neue Sachen mittlerweile mindestens 70%+ Easylan. Da ist alles aus Prinzip gemessen wenn es aus dem Karton kommt.
Selbst viele unserer Anlagenerrichter setzen mittlerweile auf Easylan. Direkt per GAEB/BIM wird das mit uns als Auftraggeber und den Lieferanten komplett digital abgewickelt. Wir zeichnen dann noch die Position und den Typs der Schnittstelle zu uns ein und alles geht seinem Weg.
Billige Kabel und Netzteile kaufen und verbauen ist der Grund für viele Feuer in Deutschland. Leider.
Selbst tote Kinder durch Ladegeräte reichen nicht.
Auch sehr unterschätzt sind die vielen billigen C12/14 Kabel die überall beiliegen. Unsere EFK bei den Begehungen sind immer wieder entzück, was alles gefunden wurde.
Wir kaufen bei losen Kabeln ausschließlich Easylan und bei den Verlegekabeln für neue Sachen mittlerweile mindestens 70%+ Easylan. Da ist alles aus Prinzip gemessen wenn es aus dem Karton kommt.
Selbst viele unserer Anlagenerrichter setzen mittlerweile auf Easylan. Direkt per GAEB/BIM wird das mit uns als Auftraggeber und den Lieferanten komplett digital abgewickelt. Wir zeichnen dann noch die Position und den Typs der Schnittstelle zu uns ein und alles geht seinem Weg.
Billige Kabel und Netzteile kaufen und verbauen ist der Grund für viele Feuer in Deutschland. Leider.
Selbst tote Kinder durch Ladegeräte reichen nicht.
Auch sehr unterschätzt sind die vielen billigen C12/14 Kabel die überall beiliegen. Unsere EFK bei den Begehungen sind immer wieder entzück, was alles gefunden wurde.
Super Beitrag wieder! Spannend zugleich! Danke Alex.
Kannst Du bitte noch zwei (vielleicht nur scheinbare) Widersprüche aufklären?
Du schreibst:
b) warum empfiehlst Du es nur bei solchen Netzen, wenn es doch jeden betrifft?
Evtl. bezieht sich die Empfehlung ja auf die Verwendung des Fluke? So ein Gerät für ab 20kEUR ist ja eher nichts fürs KMU und seinen Admin.
Und ist es nicht ohnehin wirtschaftlicher,
Viele Grüße, commodity
Kannst Du bitte noch zwei (vielleicht nur scheinbare) Widersprüche aufklären?
Du schreibst:
ein riesiges Problem ansprechen, welches buchstäblich jeden von euch betrifft!
Dann aberIch kann nach den Erfahrungen der letzten Monate, daher jedem der ein grösseres Netz betreut nur empfehlen, ...
a) was ist ein größeres Netz für Dich undb) warum empfiehlst Du es nur bei solchen Netzen, wenn es doch jeden betrifft?
Evtl. bezieht sich die Empfehlung ja auf die Verwendung des Fluke? So ein Gerät für ab 20kEUR ist ja eher nichts fürs KMU und seinen Admin.
... seine Ethernet-Channels mal mit einem anständigen LAN Qualifier alla Fluke DSX 8000, durchzutesten.
Hast Du eine Empfehlung auch eine (deutliche) Nummer kleiner?Und ist es nicht ohnehin wirtschaftlicher,
hilft schon ein Blick auf die Tx und Rx Fehlerraten, der entsprechenden Switche.
diesen Blick vorzunehmen und ggf. zu tauschen, als ein Gerät + Messaufwandszeit einzusetzen?Viele Grüße, commodity
Moin...
ich habe da eben mal Stichproben bei Kunden gemacht, da kann ich jetzt nix ungewöhnliches erkennen!
natürlich gibbet bescheidene Netzwerk Kabel, aber so dramatisch ist die Lage nun aber auch nicht.
ab 2,5 bis 5 Gbit wird es Spanender, 10 Gbit ist mit Kupfer nur auf Kurzen Wegen zu machen.
da würde ich sowiso nur SFP+ nutzen wollen!
Frank
Übrigens, um mal schnell zu prüfen ob das eigene Netzwerk von diesem Problem betroffen ist, hilft schon ein Blick auf die Tx und Rx Fehlerraten, der entsprechenden Switche.
ich habe da eben mal Stichproben bei Kunden gemacht, da kann ich jetzt nix ungewöhnliches erkennen!
natürlich gibbet bescheidene Netzwerk Kabel, aber so dramatisch ist die Lage nun aber auch nicht.
ab 2,5 bis 5 Gbit wird es Spanender, 10 Gbit ist mit Kupfer nur auf Kurzen Wegen zu machen.
da würde ich sowiso nur SFP+ nutzen wollen!
Frank
1
Moin,
ein paar Anmerkungen zu den Messungen:
galvanischen Widerstand im Milliohm-Bereich bzw bis zu wenigen 10 Ohm zu messen ist nicht ganz trivial. Ich würde da durchaus 50% Messfehler erwarten (wer misst misst Mist), zumal hier der entscheidenen Faktor die Kontaktflächen der Partner Messadapter und RJ45-Stecker sind. Die Leitungen selber geht eigentlich nur bei grober Misshandlung kaputt. Weitere Schwachstelle ist die Crimpung im Stecker, also die Schneide, die in die Litze eindringt. Kann man auch so oder so machen...
RJ 45 an für sich ist Murks aber gute Stecker erreichen durchaus bis zu 1000 Steckzyklen. D.h. nach 1000 mal rein -raus etlicher Patchkabel ist der Messadapter am Fluke wahrscheinlich hin. Im übrigen muß das Gerät einmal pro Jahr zum Kalibrieren eingeschickt werden. Was man immer machen sollte, ist, vor der eigentliche Messung mit einem Prüfkabel den Messaufbau auf Plausibilität prüfen. I.d.r. liegen da auch entsprechende Leitungen bei.
Ich wäre da jedenfalls etwas misstrausisch, wenn mir mein Messequipment dauernd "Fehler" vor allem bei fast neuen Material anzeigt.
Zumindest sollet man mal nach einem dutzend Steckspielen mal die Kontakte mit WL und Lederputzer reinigen. Das empfiehlt sich auch auf den Steckern der Patchkabel.
Viel Erfolg
ein paar Anmerkungen zu den Messungen:
galvanischen Widerstand im Milliohm-Bereich bzw bis zu wenigen 10 Ohm zu messen ist nicht ganz trivial. Ich würde da durchaus 50% Messfehler erwarten (wer misst misst Mist), zumal hier der entscheidenen Faktor die Kontaktflächen der Partner Messadapter und RJ45-Stecker sind. Die Leitungen selber geht eigentlich nur bei grober Misshandlung kaputt. Weitere Schwachstelle ist die Crimpung im Stecker, also die Schneide, die in die Litze eindringt. Kann man auch so oder so machen...
RJ 45 an für sich ist Murks aber gute Stecker erreichen durchaus bis zu 1000 Steckzyklen. D.h. nach 1000 mal rein -raus etlicher Patchkabel ist der Messadapter am Fluke wahrscheinlich hin. Im übrigen muß das Gerät einmal pro Jahr zum Kalibrieren eingeschickt werden. Was man immer machen sollte, ist, vor der eigentliche Messung mit einem Prüfkabel den Messaufbau auf Plausibilität prüfen. I.d.r. liegen da auch entsprechende Leitungen bei.
Ich wäre da jedenfalls etwas misstrausisch, wenn mir mein Messequipment dauernd "Fehler" vor allem bei fast neuen Material anzeigt.
Zumindest sollet man mal nach einem dutzend Steckspielen mal die Kontakte mit WL und Lederputzer reinigen. Das empfiehlt sich auch auf den Steckern der Patchkabel.
Viel Erfolg
3
Moin @commodity:
danke und klar sehr gerne.
Ja, meine Empfehlung für die Messung richtet sich eher an die Grösseren,
weil die eher die Kapazitäten und auch das Budget und auch das entsprechende KnowHow, für die nicht gerade günstige Prüfung haben.
Und wenn der eine oder andere der Grösseren das Problem ebenfalls mal erkannt und dem entsprechenden Hersteller ordentlich in den Hintern gedappt hat, haben die Kleinen auch was davon. ๐
Diese Widerstandsmessungen werden soweit mir bekannt ist, leider nur von Qualifier vorgenommen.
Wenn man den neuen Kabeln vertrauen könnte und diese ihre Eigenschaften auch wenigstens über ein paar Jahre behalten würden, dann ja. Jedoch trifft beides zuletzt genannte, für die Praxis leider nicht zu! ๐
Ich habe erst vor ein paar Wochen bei einem anderen Kunden, einige seine nigelnagelneuen Patchkabel die noch nie benutzt wurden, mal kurz durchgemessen und danach wurden alle von dem entsprechenden Lieferanten, durch neune und von einem anderen Hersteller stammenden Patchkabel, ersetzt.
Die neuen Patchkabel habe ich noch nicht durchgemessen.
Bei einem anderen Kunden habe ich vor Monaten einige Patchkabel durch neue ersetzt, die ich selbst vorher getestet habe. Nun, ein paar Monate später, habe ich einige dieser Strecken erneut nachgemessen und musste dabei leider feststellen, dass bei einigen der jüngst erneuerten Patchkabel, die Widerstände wieder anfangen durch die Decke zu gehen. ๐คข๐คฎ๐ญ
Gruss Alex
Super Beitrag wieder! Spannend zugleich! Danke Alex.
Kannst Du bitte noch zwei (vielleicht nur scheinbare) Widersprüche aufklären?
Kannst Du bitte noch zwei (vielleicht nur scheinbare) Widersprüche aufklären?
danke und klar sehr gerne.
Du schreibst:
b) warum empfiehlst Du es nur bei solchen Netzen, wenn es doch jeden betrifft?
Evtl. bezieht sich die Empfehlung ja auf die Verwendung des Fluke? So ein Gerät für ab 20kEUR ist ja eher nichts fürs KMU und seinen Admin.
ein riesiges Problem ansprechen, welches buchstäblich jeden von euch betrifft!
Dann aberIch kann nach den Erfahrungen der letzten Monate, daher jedem der ein grösseres Netz betreut nur empfehlen, ...
a) was ist ein größeres Netz für Dich undb) warum empfiehlst Du es nur bei solchen Netzen, wenn es doch jeden betrifft?
Evtl. bezieht sich die Empfehlung ja auf die Verwendung des Fluke? So ein Gerät für ab 20kEUR ist ja eher nichts fürs KMU und seinen Admin.
Ja, meine Empfehlung für die Messung richtet sich eher an die Grösseren,
weil die eher die Kapazitäten und auch das Budget und auch das entsprechende KnowHow, für die nicht gerade günstige Prüfung haben.
Und wenn der eine oder andere der Grösseren das Problem ebenfalls mal erkannt und dem entsprechenden Hersteller ordentlich in den Hintern gedappt hat, haben die Kleinen auch was davon. ๐
... seine Ethernet-Channels mal mit einem anständigen LAN Qualifier alla Fluke DSX 8000, durchzutesten.
Hast Du eine Empfehlung auch eine (deutliche) Nummer kleiner?Diese Widerstandsmessungen werden soweit mir bekannt ist, leider nur von Qualifier vorgenommen.
Und ist es nicht ohnehin wirtschaftlicher,
hilft schon ein Blick auf die Tx und Rx Fehlerraten, der entsprechenden Switche.
diesen Blick vorzunehmen und ggf. zu tauschen, als ein Gerät + Messaufwandszeit einzusetzen?Wenn man den neuen Kabeln vertrauen könnte und diese ihre Eigenschaften auch wenigstens über ein paar Jahre behalten würden, dann ja. Jedoch trifft beides zuletzt genannte, für die Praxis leider nicht zu! ๐
Ich habe erst vor ein paar Wochen bei einem anderen Kunden, einige seine nigelnagelneuen Patchkabel die noch nie benutzt wurden, mal kurz durchgemessen und danach wurden alle von dem entsprechenden Lieferanten, durch neune und von einem anderen Hersteller stammenden Patchkabel, ersetzt.
Die neuen Patchkabel habe ich noch nicht durchgemessen.
Bei einem anderen Kunden habe ich vor Monaten einige Patchkabel durch neue ersetzt, die ich selbst vorher getestet habe. Nun, ein paar Monate später, habe ich einige dieser Strecken erneut nachgemessen und musste dabei leider feststellen, dass bei einigen der jüngst erneuerten Patchkabel, die Widerstände wieder anfangen durch die Decke zu gehen. ๐คข๐คฎ๐ญ
Gruss Alex
Moin Frank,
leih dir mal einen Fluke oder vergleichbares aus und messe mal Stichprobenweise mit einem Qualifier durch.
Ich verspreche dir, dann wirst du schon sehen was ich meine. ๐
Frank, selbst wenn man will, kann man nicht überall LWL benutzen, weil vor allen die günstigeren Geräte, meist überhaupt keinen LWL Slot haben. Und spätestens wenn es um das Thema POE geht, ist LWL eh raus.
Und ohne POE, würde ich selbst z.B. keine grösseres W-LAN, weder installieren noch betreiben wollen.
Gruss Alex
natürlich gibbet bescheidene Netzwerk Kabel, aber so dramatisch ist die Lage nun aber auch nicht.
leih dir mal einen Fluke oder vergleichbares aus und messe mal Stichprobenweise mit einem Qualifier durch.
Ich verspreche dir, dann wirst du schon sehen was ich meine. ๐
ab 2,5 bis 5 Gbit wird es Spanender, 10 Gbit ist mit Kupfer nur auf Kurzen Wegen zu machen.
da würde ich sowiso nur SFP+ nutzen wollen!
da würde ich sowiso nur SFP+ nutzen wollen!
Frank, selbst wenn man will, kann man nicht überall LWL benutzen, weil vor allen die günstigeren Geräte, meist überhaupt keinen LWL Slot haben. Und spätestens wenn es um das Thema POE geht, ist LWL eh raus.
Und ohne POE, würde ich selbst z.B. keine grösseres W-LAN, weder installieren noch betreiben wollen.
Gruss Alex
Moin @dbru61,
wenn man mit einem 0815 Multimeter testen würde, dann vielleicht ja.
Der DSX 8000 misst jedoch auf 0,0x Ohm genau und lässt sich zudem jederzeit im Feld durch "SET REFFERENCE" rekalibrieren. ๐
Ja, ich sehe schon, du hast dich mit diesem Thema auch schon etwas tiefer beschäftigt.
Und ja, die Piercing-Kontaktierung der meisten Patchkabel, ist meinen bisherigen Nachforschungen nach die Hauptursache für das oben angesprochene Problem. ๐
Genaueres dazu, würde ich aber separat in einer anderen Episode später noch ansprechen. ๐
Na ja, in 99% wird nun mal gepierct. ๐ญ
Mir ist bisher nur ein einziger Patchkabel Hersteller bekannt, der auch bei Patchkabeln Schneidklemmen verwendet und das ist R&M.
https://www.rdm.com
Ja, aber daher haben die PCA's von Fluke auch austauschbare Messbuchsen, die nach 1000 bis 1500 Messungen getauscht werden sollten. ๐
Unser Fluke ist gerade mal ein halbes Jahr alt und wie du an meiner oberen Bemerkung erkennen kannst, ist mir das Procedere der "Ferldkalibrierung" durchaus bekannt. ๐
Dass unser Fluke nur Fehler anzeigt, habe ich zum einen nirgends geschrieben, zum anderen haben wir mit diesem auch schon einige hundert neuer Patchkabel von Namenhaften Herstellern durchgemessen, die zum grössten Teil, die Prüfung positiv bestanden haben. ๐
Aber wie schon geschrieben, auch bei diesen gab es nach einer sehr kurzen Einsatzzeit, schon sehr fragwürdige Alterungserscheinungen. ๐
Wenn, dann aber sehr vorsichtig, den ansonsten besteht die Gefahr, dass man mit einer solchen Aktion, die filigranen Kontakte in der Buchse eher beschädigt und dadurch im schlimmsten Fall den ganzen Messadapter unbrauchbar macht.
Gruss Alex
galvanischen Widerstand im Milliohm-Bereich bzw bis zu wenigen 10 Ohm zu messen ist nicht ganz trivial. Ich würde da durchaus 50% Messfehler erwarten (wer misst misst Mist), zumal hier der entscheidenen Faktor die Kontaktflächen der Partner Messadapter und RJ45-Stecker sind.
wenn man mit einem 0815 Multimeter testen würde, dann vielleicht ja.
Der DSX 8000 misst jedoch auf 0,0x Ohm genau und lässt sich zudem jederzeit im Feld durch "SET REFFERENCE" rekalibrieren. ๐
Weitere Schwachstelle ist die Crimpung im Stecker, also die Schneide, die in die Litze eindringt.
Ja, ich sehe schon, du hast dich mit diesem Thema auch schon etwas tiefer beschäftigt.
Und ja, die Piercing-Kontaktierung der meisten Patchkabel, ist meinen bisherigen Nachforschungen nach die Hauptursache für das oben angesprochene Problem. ๐
Genaueres dazu, würde ich aber separat in einer anderen Episode später noch ansprechen. ๐
Kann man auch so oder so machen...
Na ja, in 99% wird nun mal gepierct. ๐ญ
Mir ist bisher nur ein einziger Patchkabel Hersteller bekannt, der auch bei Patchkabeln Schneidklemmen verwendet und das ist R&M.
https://www.rdm.com
RJ 45 an für sich ist Murks aber gute Stecker erreichen durchaus bis zu 1000 Steckzyklen. D.h. nach 1000 mal rein -raus etlicher Patchkabel ist der Messadapter am Fluke wahrscheinlich hin.
Ja, aber daher haben die PCA's von Fluke auch austauschbare Messbuchsen, die nach 1000 bis 1500 Messungen getauscht werden sollten. ๐
Im übrigen muß das Gerät einmal pro Jahr zum Kalibrieren eingeschickt werden. Was man immer machen sollte, ist, vor der eigentliche Messung mit einem Prüfkabel den Messaufbau auf Plausibilität prüfen. I.d.r. liegen da auch entsprechende Leitungen bei.
Unser Fluke ist gerade mal ein halbes Jahr alt und wie du an meiner oberen Bemerkung erkennen kannst, ist mir das Procedere der "Ferldkalibrierung" durchaus bekannt. ๐
Ich wäre da jedenfalls etwas misstrausisch, wenn mir mein Messequipment dauernd "Fehler" vor allem bei fast neuen Material anzeigt.
Dass unser Fluke nur Fehler anzeigt, habe ich zum einen nirgends geschrieben, zum anderen haben wir mit diesem auch schon einige hundert neuer Patchkabel von Namenhaften Herstellern durchgemessen, die zum grössten Teil, die Prüfung positiv bestanden haben. ๐
Aber wie schon geschrieben, auch bei diesen gab es nach einer sehr kurzen Einsatzzeit, schon sehr fragwürdige Alterungserscheinungen. ๐
Zumindest sollet man mal nach einem dutzend Steckspielen mal die Kontakte mit WL und Lederputzer reinigen.
Wenn, dann aber sehr vorsichtig, den ansonsten besteht die Gefahr, dass man mit einer solchen Aktion, die filigranen Kontakte in der Buchse eher beschädigt und dadurch im schlimmsten Fall den ganzen Messadapter unbrauchbar macht.
Gruss Alex
Moin,
Frank, selbst wenn man will, kann man nicht überall LWL benutzen, weil vor allen die günstigeren Geräte, meist überhaupt keinen LWL Slot haben. Und spätestens wenn es um das Thema POE geht, ist LWL eh raus.
Und ohne POE, würde ich selbst z.B. keine grösseres W-LAN, weder installieren noch betreiben wollen.
die günstigeren Geräte haben auch kein GUI um Tx und Rx Fehlerraten anzuschauen.... 
W-LAN ohne POE ist naturlich Doof klar, egal ob klein oder groß.
ich habe fast keine Kunden, die nicht FSP+ , QSFP+ oder höher haben, und natürlich cat 6 und 7. Der rest hat noch Cat5 inne Wand liegen- wenn ich mit dem Fluke angerannt komme, und messen würde, sagt der Kunde zu mir, ja und, wir haben keine Fehler, alles rennt wie es soll!
und wenn ich mit Patchkabel für 50 euro das Stück komme, und sage, bestell mal 30 Stück, Lacht der Kunde die nächsten 3 Tage noch über mich!
klingt wie ein geschäftsmodell
natürlich messen wir neue verkabelungen von diversen Elektrickern selber noch mal aus, besonders wenn du 200 x die gleichen werte bekommst!
ach ja... POE, hast du mal geschaut was diverse POE injektoren mit deinem Signal macht? da wirst du Bauklötze staunen, und dein geliehener Fluke tantzt Samba
natürlich haben zertifizierte Kabel ihr berechtigung, keine frage, und eine neue verkabelung sollte schon sauber sein!
frank
Gruss Alex
Zitat von @MysticFoxDE:
Moin Frank,
leih dir mal einen Fluke oder vergleichbares aus und messe mal Stichprobenweise mit einem Qualifier durch.
Ich verspreche dir, dann wirst du schon sehen was ich meine. ๐
den haben wir!Moin Frank,
natürlich gibbet bescheidene Netzwerk Kabel, aber so dramatisch ist die Lage nun aber auch nicht.
leih dir mal einen Fluke oder vergleichbares aus und messe mal Stichprobenweise mit einem Qualifier durch.
Ich verspreche dir, dann wirst du schon sehen was ich meine. ๐
ab 2,5 bis 5 Gbit wird es Spanender, 10 Gbit ist mit Kupfer nur auf Kurzen Wegen zu machen.
da würde ich sowiso nur SFP+ nutzen wollen!
da würde ich sowiso nur SFP+ nutzen wollen!
Frank, selbst wenn man will, kann man nicht überall LWL benutzen, weil vor allen die günstigeren Geräte, meist überhaupt keinen LWL Slot haben. Und spätestens wenn es um das Thema POE geht, ist LWL eh raus.
Und ohne POE, würde ich selbst z.B. keine grösseres W-LAN, weder installieren noch betreiben wollen.
W-LAN ohne POE ist naturlich Doof klar, egal ob klein oder groß.
ich habe fast keine Kunden, die nicht FSP+ , QSFP+ oder höher haben, und natürlich cat 6 und 7. Der rest hat noch Cat5 inne Wand liegen- wenn ich mit dem Fluke angerannt komme, und messen würde, sagt der Kunde zu mir, ja und, wir haben keine Fehler, alles rennt wie es soll!
und wenn ich mit Patchkabel für 50 euro das Stück komme, und sage, bestell mal 30 Stück, Lacht der Kunde die nächsten 3 Tage noch über mich!
Ja, meine Empfehlung für die Messung richtet sich eher an die Grösseren,
weil die eher die Kapazitäten und auch das Budget und auch das entsprechende KnowHow, für die nicht gerade günstige Prüfung haben.klingt wie ein geschäftsmodell
natürlich messen wir neue verkabelungen von diversen Elektrickern selber noch mal aus, besonders wenn du 200 x die gleichen werte bekommst!
ach ja... POE, hast du mal geschaut was diverse POE injektoren mit deinem Signal macht? da wirst du Bauklötze staunen, und dein geliehener Fluke tantzt Samba
natürlich haben zertifizierte Kabel ihr berechtigung, keine frage, und eine neue verkabelung sollte schon sauber sein!
frank
Gruss Alex
1
Moin @dbru61,
ich hoffe das beruhigt dich nun ein bisschen. ๐
Zudem ist es auch noch ein kleiner Spoiler auf das noch kommende. ๐คช
Gruss Alex
Ich wäre da jedenfalls etwas misstrausisch, wenn mir mein Messequipment dauernd "Fehler" vor allem bei fast neuen Material anzeigt.
ich hoffe das beruhigt dich nun ein bisschen. ๐
Zudem ist es auch noch ein kleiner Spoiler auf das noch kommende. ๐คช
Gruss Alex
Hallo
Sorry, stehe gerade auf dem Schlauch - was meinst du mit „WL“?
Grüße
TA
Zitat von @dbru61:
Zumindest sollet man mal nach einem dutzend Steckspielen mal die Kontakte mit WL und Lederputzer reinigen. Das empfiehlt sich auch auf den Steckern der Patchkabel.
Zumindest sollet man mal nach einem dutzend Steckspielen mal die Kontakte mit WL und Lederputzer reinigen. Das empfiehlt sich auch auf den Steckern der Patchkabel.
Sorry, stehe gerade auf dem Schlauch - was meinst du mit „WL“?
Grüße
TA
Moin Frank,
๐ … ist es vielleicht auch ein DSX von Fluke?
Ja, das kommt erschwerend hinzu, daher auch mein Wink an die eher etwas grösseren, die die entsprechende Hardware haben sollten. ๐
Na ja, wenn ich die Admins bei den Firmen nach Problemen frage, bekomme ich meistens zu hören, dass es eigentlich so gut wie keine gibt. Wenn ich dann aber direkt die User anspreche, bekomme ich sehr oft genau das Gegenteil erzählt. ๐
Ich habe jetzt zwar schon mehrfach die R&M Patchkabel als mögliche Lösung für diese Problem angesprochen, weil diese im Vergleich zu so gut wie allen anderen nicht auf die piercing Kontaktierung setzen, sondern auf Schneidklemmen. Und ja, diese sind etwas teurer als gewöhnliche Patchkabel, aber noch lange keine 50,- €.
Ausserdem, wenn einem User X Mal am Tag seine Software aufgrund einer schlechter Netzwerkverkabelung abschmiert, kostet das das entsprechende Unternehmen, ratz fatz viel mehr wie nur 50,-€.
Ähm, da hast du mich aber kräftig missverstanden!
Die sollen das bitte selber machen, dafür haben wir überhaupt nicht mal ansatzweise die entsprechenden Kapazitäten.
Nö, weil ich die Dinger genau aus diesem Grund hasse und daher im Vorfeld schon versuche möglichst zu meiden.
Nix geliehen. Nach x Mal pro Jahr leihen, haben wir uns dieses Jahr selber einen rausgelassen. ๐
Ähm, was das angeht, so muss ich dich in einer der nächsten Episoden, fürchte ich kräftigst enttäuschen. ๐
Kleiner Spoiler, die angesprochene „Widerstandsunsymmetriemessung“ ist bis heute kein verpflichtender Teil einer Patchkabel Qualifizierung. ๐ฌ
Näheres dazu kommt in einer der nächsten Episoden.
Ja, definitiv.
Aber, dass die alte Festverkabelung noch das hergibt was möglich ist, wird mit der immer höher werdenden Bandbreite, auch immer wichtiger.
Denn eine bestehende Netzwerkverkabelung komplett zu ersetzen, ist nochmals eine ganz andere Baustelle, als nur die Patchpanels/Buchsen/Dosen und oder Patchkabel zu tauschen, damit die Alte etwas flotter wird. ๐คช
Gruss Alex
den haben wir!
๐ … ist es vielleicht auch ein DSX von Fluke?
die günstigeren Geräte haben auch kein GUI um Tx und Rx Fehlerraten anzuschauen....
Ja, das kommt erschwerend hinzu, daher auch mein Wink an die eher etwas grösseren, die die entsprechende Hardware haben sollten. ๐
ich habe fast keine Kunden, die nicht FSP+ , QSFP+ oder höher haben, und natürlich cat 6 und 7. Der rest hat noch Cat5 inne Wand liegen- wenn ich mit dem Fluke angerannt komme, und messen würde, sagt der Kunde zu mir, ja und, wir haben keine Fehler, alles rennt wie es soll!
Na ja, wenn ich die Admins bei den Firmen nach Problemen frage, bekomme ich meistens zu hören, dass es eigentlich so gut wie keine gibt. Wenn ich dann aber direkt die User anspreche, bekomme ich sehr oft genau das Gegenteil erzählt. ๐
und wenn ich mit Patchkabel für 50 euro das Stück komme, und sage, bestell mal 30 Stück, Lacht der Kunde die nächsten 3 Tage noch über mich!
Ich habe jetzt zwar schon mehrfach die R&M Patchkabel als mögliche Lösung für diese Problem angesprochen, weil diese im Vergleich zu so gut wie allen anderen nicht auf die piercing Kontaktierung setzen, sondern auf Schneidklemmen. Und ja, diese sind etwas teurer als gewöhnliche Patchkabel, aber noch lange keine 50,- €.
Ausserdem, wenn einem User X Mal am Tag seine Software aufgrund einer schlechter Netzwerkverkabelung abschmiert, kostet das das entsprechende Unternehmen, ratz fatz viel mehr wie nur 50,-€.
klingt wie ein geschäftsmodell
Ähm, da hast du mich aber kräftig missverstanden!
Die sollen das bitte selber machen, dafür haben wir überhaupt nicht mal ansatzweise die entsprechenden Kapazitäten.
ach ja... POE, hast du mal geschaut was diverse POE injektoren mit deinem Signal macht? da wirst du Bauklötze staunen
Nö, weil ich die Dinger genau aus diesem Grund hasse und daher im Vorfeld schon versuche möglichst zu meiden.
und dein geliehener Fluke tantzt Samba
Nix geliehen. Nach x Mal pro Jahr leihen, haben wir uns dieses Jahr selber einen rausgelassen. ๐
natürlich haben zertifizierte Kabel ihr berechtigung, keine frage
Ähm, was das angeht, so muss ich dich in einer der nächsten Episoden, fürchte ich kräftigst enttäuschen. ๐
Kleiner Spoiler, die angesprochene „Widerstandsunsymmetriemessung“ ist bis heute kein verpflichtender Teil einer Patchkabel Qualifizierung. ๐ฌ
Näheres dazu kommt in einer der nächsten Episoden.
und eine neue verkabelung sollte schon sauber sein!
Ja, definitiv.
Aber, dass die alte Festverkabelung noch das hergibt was möglich ist, wird mit der immer höher werdenden Bandbreite, auch immer wichtiger.
Denn eine bestehende Netzwerkverkabelung komplett zu ersetzen, ist nochmals eine ganz andere Baustelle, als nur die Patchpanels/Buchsen/Dosen und oder Patchkabel zu tauschen, damit die Alte etwas flotter wird. ๐คช
Gruss Alex
Nabend,
guck dir mal bitte die Köpfe an ob du das gleiche Problem hast wie ich bei meinen Kabeln:
RNS Patchkabel mit gesplittertem Kรถpfen (eventuell Produktionsfehler?)
p.s. inzwischen habe ich erneut Kabel tauschen müssen. Bei einen Kunden sind 2 von 3 POE-Kameras ständig ausgefallen. Alle drei Kabel gesplitterte Köpfe, 2 davon problematisch, eins funktioniert.
guck dir mal bitte die Köpfe an ob du das gleiche Problem hast wie ich bei meinen Kabeln:
RNS Patchkabel mit gesplittertem Kรถpfen (eventuell Produktionsfehler?)
p.s. inzwischen habe ich erneut Kabel tauschen müssen. Bei einen Kunden sind 2 von 3 POE-Kameras ständig ausgefallen. Alle drei Kabel gesplitterte Köpfe, 2 davon problematisch, eins funktioniert.
1
Moin @anteNope,
๐ฎ... danke für den Hinweis ... ๐๐ ... und nein, dieses Problem kannte ich so bewusst auch noch nicht.
Gruss Alex
guck dir mal bitte die Köpfe an ob du das gleiche Problem hast wie ich bei meinen Kabeln:
RNS Patchkabel mit gesplittertem Kรถpfen (eventuell Produktionsfehler?)
RNS Patchkabel mit gesplittertem Kรถpfen (eventuell Produktionsfehler?)
๐ฎ... danke für den Hinweis ... ๐๐ ... und nein, dieses Problem kannte ich so bewusst auch noch nicht.
Gruss Alex
@alex (MysticFoxDE)
Sehr gute und interessante Folge.
Ich setze noch noch einen dazu. Man sollte regelmäßig das Glasfaser überprüfen und putzen. Wir hatten im Har 2020 einen externen Dienstleister im Haus, welcher an einem Standort die Glasfaserleitungen mit dem Mickroskop stichprobenartig geprüft hat. Und es taten sich Abgründe auf.
Die Netzwerker meinten IMMER, das ist nicht sooo relevant. Und wurde eines besseren belehrt.
P.S. Ich hoffe Du kommst auch zum Glasfaserthema.
Gruss Penny.
Sehr gute und interessante Folge.
Ich setze noch noch einen dazu. Man sollte regelmäßig das Glasfaser überprüfen und putzen. Wir hatten im Har 2020 einen externen Dienstleister im Haus, welcher an einem Standort die Glasfaserleitungen mit dem Mickroskop stichprobenartig geprüft hat. Und es taten sich Abgründe auf.
Die Netzwerker meinten IMMER, das ist nicht sooo relevant. Und wurde eines besseren belehrt.
P.S. Ich hoffe Du kommst auch zum Glasfaserthema.
Gruss Penny.
1
Moin @Penny.Cilin,
< danke.
Oh ja, das kann ich nur bestätigen.
Daher haben wir uns lange vor dem DSX 8000, schon einen FiberInspector angheschaft.
https://de.flukenetworks.com/datacom-cabling/Versiv/FI-7000
Den Bilder sagen bekanntlich mehr als tausend Worte. ๐
Kann ich gerne auch noch machen, in diesem Bereich ist definitiv auch nicht alles koscher.
Ich fürchte jedoch, dass ich die nächste Zeit noch ordentlich mit dem Kupferthema beschäftigt bin. ๐ฉ
Beste Grüsse aus BaWü
Alex
Sehr gute und interessante Folge.
< danke.
Ich setze noch noch einen dazu. Man sollte regelmäßig das Glasfaser überprüfen und putzen. Wir hatten im Har 2020 einen externen Dienstleister im Haus, welcher an einem Standort die Glasfaserleitungen mit dem Mickroskop stichprobenartig geprüft hat. Und es taten sich Abgründe auf.
Die Netzwerker meinten IMMER, das ist nicht sooo relevant. Und wurde eines besseren belehrt.
Die Netzwerker meinten IMMER, das ist nicht sooo relevant. Und wurde eines besseren belehrt.
Oh ja, das kann ich nur bestätigen.
Daher haben wir uns lange vor dem DSX 8000, schon einen FiberInspector angheschaft.
https://de.flukenetworks.com/datacom-cabling/Versiv/FI-7000
Den Bilder sagen bekanntlich mehr als tausend Worte. ๐
P.S. Ich hoffe Du kommst auch zum Glasfaserthema.
Kann ich gerne auch noch machen, in diesem Bereich ist definitiv auch nicht alles koscher.
Ich fürchte jedoch, dass ich die nächste Zeit noch ordentlich mit dem Kupferthema beschäftigt bin. ๐ฉ
Beste Grüsse aus BaWü
Alex
Ab wie groß etwa?
Du schreibst doch oben, dass das Problem für alle relevant ist. Würde es nicht einen Markt für entsprechende Prüfgeräte geben, wenn es für die kleineren Netze auch relevant wäre? Oder hängt das mit der Last zusammen, die in größeren (teilweise) Netzen evtl. herrscht?
Viele Grüße, commodity
Hast Du eine Empfehlung auch eine (deutliche) Nummer kleiner?
Diese Widerstandsmessungen werden soweit mir bekannt ist, leider nur von Qualifier vorgenommen.Viele Grüße, commodity
Ich denke Mal, es hängt mit der Last zusammen. Wenn man beim Netzwerkmonitoring feststellt, das die Switches permanent die Fehler bereinigt. Dann weiß man, das etwas faul ist.
Gruss Penny.
Gruss Penny.
Wenn ein Switch wirespeed arbeitet wird es ja wohl kaum an der Last liegen. Und auch wenn nicht würde der Switch still und heimlich Frames droppen und die Endgeräte selber müssten dann retransmitten sofern TCP der Transport ist. Bei UDP sind die Frames hat halt einfach wech.
Nur um es nicht misszuverstehen: Weder ein L2 noch ein L3 Switch "bereinigt" kaputtes Framing! Und das gilt sowohl bei einem Store and Forward Switch als auch bei einem Cut Through Switch. Solche Frames wären ja per se gar nicht lesbar und landen bei Switches deshalb schlicht und einfach im Datenmülleimer und wenn man Glück hat bei entsprechendem Featureset, wird noch ein Errorcounter inkrementiert.
Nur um es nicht misszuverstehen: Weder ein L2 noch ein L3 Switch "bereinigt" kaputtes Framing! Und das gilt sowohl bei einem Store and Forward Switch als auch bei einem Cut Through Switch. Solche Frames wären ja per se gar nicht lesbar und landen bei Switches deshalb schlicht und einfach im Datenmülleimer und wenn man Glück hat bei entsprechendem Featureset, wird noch ein Errorcounter inkrementiert.
2
Moin @commodity,
die Frage ist echt schwer zu beantworten.
Wenn das Unternehmen klein ist und die User nicht viele Daten über das Netz transportiert und z.B. überwiegend über RDP arbeiten, dann wird dieser Kunde auch nicht viele Probleme haben, den das funktioniert zur Not auch noch über 10MBit/s, ohne dass der User grossartig was merkt.
Bei einem Betrieben ab einigen hundert Ports, sieht die Sache meistens schon etwas anders aus, weil hier auch normalerweise deutlich mehr und auch kritischere Daten durch das Netz bewegt werden.
Auf der Anderen Seite möchte ich die folgende Erfahrung auch nicht verheimlichen.
Ich habe mit dem DSX natürlich auch schon meine zuhause verwendeten Patchkabel durchgemessen und danach die meisten davon durch neue ersetzt. ๐
Seit der Aktion, habe ich mit der PS5 auch viel weniger Probleme beim Onlinezocken. ๐
Ist es auch, siehe meine Bemerkung bez. PS5. ๐
Nur kann sich aber nicht jeder Kleine und vor allem Privatpersonen, mal kurz einen DSX leihen.
Vor allem bring alleine das Ausleihen eines Qualifiers, den Meisten nicht wirklich etwas, weil man so ein Ding auch korrekt bedienen muss, damit das Messergebnis am Ende auch verwertbar ist.
Zudem hat auch jeder Qualifier seine eigenen Krankheiten, die man kennen muss, die aber nirgends beschrieben sind. ๐
Es gibt ja die entsprechenden Prüfgeräte, nur sind diese für die meisten Nutzer am Markt viel zu teuer, daher hat der Markt das Problem auch noch gar nicht wirklich erkannt.
Zudem kommt noch erschwerend hinzu, dass die meisten verfügbaren Qualifier und auch der DSX, genau dieses Widerstandsproblem per Default nicht ankreiden, da die entsprechende Messung/Prüfung, kein verpflichtender Bestandteil einer Patchkabel-Qualifizierung ist. ๐คข๐คฎ
Um diesem Problem z.B. mit einem Fluke DSX auf die Schliche zu kommen, musst du unbedingt die "CHANNEL ADAPTER" benutzen und z.B. mit den Testlimits "ISO11801 Channel Class D (+All)" oder "ISO11801 Channel Class E (+All)" oder "ISO11801 Channel Class Ea (+All)", testen. ๐
Auch, da das Problem besonders bei der Ausnutzung der vollen Bandbreite, häufiger zu Störungen führt.
Beste Grüsse aus BaWü
Alex
Ab wie groß etwa?
die Frage ist echt schwer zu beantworten.
Wenn das Unternehmen klein ist und die User nicht viele Daten über das Netz transportiert und z.B. überwiegend über RDP arbeiten, dann wird dieser Kunde auch nicht viele Probleme haben, den das funktioniert zur Not auch noch über 10MBit/s, ohne dass der User grossartig was merkt.
Bei einem Betrieben ab einigen hundert Ports, sieht die Sache meistens schon etwas anders aus, weil hier auch normalerweise deutlich mehr und auch kritischere Daten durch das Netz bewegt werden.
Auf der Anderen Seite möchte ich die folgende Erfahrung auch nicht verheimlichen.
Ich habe mit dem DSX natürlich auch schon meine zuhause verwendeten Patchkabel durchgemessen und danach die meisten davon durch neue ersetzt. ๐
Seit der Aktion, habe ich mit der PS5 auch viel weniger Probleme beim Onlinezocken. ๐
Du schreibst doch oben, dass das Problem für alle relevant ist.
Ist es auch, siehe meine Bemerkung bez. PS5. ๐
Nur kann sich aber nicht jeder Kleine und vor allem Privatpersonen, mal kurz einen DSX leihen.
Vor allem bring alleine das Ausleihen eines Qualifiers, den Meisten nicht wirklich etwas, weil man so ein Ding auch korrekt bedienen muss, damit das Messergebnis am Ende auch verwertbar ist.
Zudem hat auch jeder Qualifier seine eigenen Krankheiten, die man kennen muss, die aber nirgends beschrieben sind. ๐
Würde es nicht einen Markt für entsprechende Prüfgeräte geben, wenn es für die kleineren Netze auch relevant wäre?
Es gibt ja die entsprechenden Prüfgeräte, nur sind diese für die meisten Nutzer am Markt viel zu teuer, daher hat der Markt das Problem auch noch gar nicht wirklich erkannt.
Zudem kommt noch erschwerend hinzu, dass die meisten verfügbaren Qualifier und auch der DSX, genau dieses Widerstandsproblem per Default nicht ankreiden, da die entsprechende Messung/Prüfung, kein verpflichtender Bestandteil einer Patchkabel-Qualifizierung ist. ๐คข๐คฎ
Um diesem Problem z.B. mit einem Fluke DSX auf die Schliche zu kommen, musst du unbedingt die "CHANNEL ADAPTER" benutzen und z.B. mit den Testlimits "ISO11801 Channel Class D (+All)" oder "ISO11801 Channel Class E (+All)" oder "ISO11801 Channel Class Ea (+All)", testen. ๐
Oder hängt das mit der Last zusammen, die in größeren (teilweise) Netzen evtl. herrscht?
Auch, da das Problem besonders bei der Ausnutzung der vollen Bandbreite, häufiger zu Störungen führt.
Beste Grüsse aus BaWü
Alex
Moin @Penny.Cilin,
ja genau so ist das, zumindest bis auf den Punkt, dass ein Switch einen fehlerhaftes Packet nicht wirklich bereinigen/korrigieren, sondern nur wegwerfen/ignorieren kann.
Gruss Alex
Ich denke Mal, es hängt mit der Last zusammen. Wenn man beim Netzwerkmonitoring feststellt, das die Switches permanent die Fehler bereinigt. Dann weiß man, das etwas faul ist.
ja genau so ist das, zumindest bis auf den Punkt, dass ein Switch einen fehlerhaftes Packet nicht wirklich bereinigen/korrigieren, sondern nur wegwerfen/ignorieren kann.
Gruss Alex
1
Moin @aqui,
ähm, leider doch.
Ich habe jetzt schon duzende Male beobachtet, dass z.B. die Tx oder Rx Fehler an den Switchen, erst dann anfangen nach oben zu klettern, wenn eine bestimmte Lastgrenze überschritten wird.
Dasselbe Problem habe ich übrigens nicht nur bei Kupfer, sondern auch schon häufiger bei LWL Links gesehen. ๐
Erst dem Letzt hat einer unserer Kunden sein ca. 100kg schweres Backup-SAN, in den Primären Serverraum schleppen müssen, weil ein Restore aufgrund von Übertragungsfehlern innerhalb der entsprechenden LWL Strecken (4x10G), ständig abgeschmiert ist. ๐คฎ
Gruss Alex
Wenn ein Switch wirespeed arbeitet wird es ja wohl kaum an der Last liegen.
ähm, leider doch.
Ich habe jetzt schon duzende Male beobachtet, dass z.B. die Tx oder Rx Fehler an den Switchen, erst dann anfangen nach oben zu klettern, wenn eine bestimmte Lastgrenze überschritten wird.
Dasselbe Problem habe ich übrigens nicht nur bei Kupfer, sondern auch schon häufiger bei LWL Links gesehen. ๐
Erst dem Letzt hat einer unserer Kunden sein ca. 100kg schweres Backup-SAN, in den Primären Serverraum schleppen müssen, weil ein Restore aufgrund von Übertragungsfehlern innerhalb der entsprechenden LWL Strecken (4x10G), ständig abgeschmiert ist. ๐คฎ
Gruss Alex
Danke für die Erläuterungen, Alex. Echt klasse!
Viele Grüße, commodity
Viele Grüße, commodity
Zitat von @MysticFoxDE:
Moin @aqui,
ähm, leider doch.
Ich habe jetzt schon duzende Male beobachtet, dass z.B. die Tx oder Rx Fehler an den Switchen, erst dann anfangen nach oben zu klettern, wenn eine bestimmte Lastgrenze überschritten wird.
Dasselbe Problem habe ich übrigens nicht nur bei Kupfer, sondern auch schon häufiger bei LWL Links gesehen. ๐
Erst dem Letzt hat einer unserer Kunden sein ca. 100kg schweres Backup-SAN, in den Primären Serverraum schleppen müssen, weil ein Restore aufgrund von Übertragungsfehlern innerhalb der entsprechenden LWL Strecken (4x10G), ständig abgeschmiert ist. ๐คฎ
Gruss Alex
Moin @aqui,
Wenn ein Switch wirespeed arbeitet wird es ja wohl kaum an der Last liegen.
ähm, leider doch.
Ich habe jetzt schon duzende Male beobachtet, dass z.B. die Tx oder Rx Fehler an den Switchen, erst dann anfangen nach oben zu klettern, wenn eine bestimmte Lastgrenze überschritten wird.
Dasselbe Problem habe ich übrigens nicht nur bei Kupfer, sondern auch schon häufiger bei LWL Links gesehen. ๐
Erst dem Letzt hat einer unserer Kunden sein ca. 100kg schweres Backup-SAN, in den Primären Serverraum schleppen müssen, weil ein Restore aufgrund von Übertragungsfehlern innerhalb der entsprechenden LWL Strecken (4x10G), ständig abgeschmiert ist. ๐คฎ
Gruss Alex
Deshalb gibt es zertifizierte Switches mit diversen lossless Features.
Moin @8585324113,
FEC (Forward Error Correction) gibt es erst ab 25G und ansonsten ist mir bei keinem Switch eine Feature bekannt, welches Übertragungsfehler korrigieren/berichtigen kann.
Gruss Alex
Deshalb gibt es zertifizierte Switches mit diversen lossless Features.
FEC (Forward Error Correction) gibt es erst ab 25G und ansonsten ist mir bei keinem Switch eine Feature bekannt, welches Übertragungsfehler korrigieren/berichtigen kann.
Gruss Alex
DCB, FCoE usw...
Die Liste ist mittlerweile lang.
Bezüglich von echten Übertragungsfehlern, losgelöst von den Konsequenzen kann man beim Ethernet selbst anfangen bei einer IP Kommunikation mit z. B. TCP.
Entscheiden finde ich, dass das Switch auf allen Ports trommelt und die Latenzen niedrig bleiben.
Wenn man vor einem nVidia oder Force10 Switch steht das mit 100/400GBits Ports 5000+ Mpps kann in Nanosekundenbereich, dann hat Linespeed eine ganz neue Bedeutung.
Die Liste ist mittlerweile lang.
Bezüglich von echten Übertragungsfehlern, losgelöst von den Konsequenzen kann man beim Ethernet selbst anfangen bei einer IP Kommunikation mit z. B. TCP.
Entscheiden finde ich, dass das Switch auf allen Ports trommelt und die Latenzen niedrig bleiben.
Wenn man vor einem nVidia oder Force10 Switch steht das mit 100/400GBits Ports 5000+ Mpps kann in Nanosekundenbereich, dann hat Linespeed eine ganz neue Bedeutung.
Moin @8585324113,
๐ฎ ... auch noch FCoE ... ๐ฑ ... nein, bitte aufhören, da bekomme ich überall nur furchtbare Krämpfe, vor allem wenn ich an Dinge wie Effizienz und oder Transaktionsperformance denke.
Ja, vor allem die richtige Konfiguration der NIC am anderen Ende, insbesondere wenn diese von einem Windows angesteuert werden, kann alleine schon ein Drama für sich werden. ๐
Und komme mir jetzt bitte nicht mir RDMA. Den selbst mit RDMA, kommst du noch lange nicht an die Effizienz einer nativen Storageanbindung per FC oder SAS heran, vor allem nicht bei kleinen fiesen Transaktionen im KB Bereich, die auch heute noch, bei den Meisten mehr als alltäglich sind. ๐
Gruss Alex
DCB, FCoE usw...
๐ฎ ... auch noch FCoE ... ๐ฑ ... nein, bitte aufhören, da bekomme ich überall nur furchtbare Krämpfe, vor allem wenn ich an Dinge wie Effizienz und oder Transaktionsperformance denke.
Wenn man vor einem nVidia oder Force10 Switch steht das mit 100/400GBits Ports 5000+ Mpps kann in Nanosekundenbereich, dann hat Linespeed eine ganz neue Bedeutung.
Ja, vor allem die richtige Konfiguration der NIC am anderen Ende, insbesondere wenn diese von einem Windows angesteuert werden, kann alleine schon ein Drama für sich werden. ๐
Und komme mir jetzt bitte nicht mir RDMA. Den selbst mit RDMA, kommst du noch lange nicht an die Effizienz einer nativen Storageanbindung per FC oder SAS heran, vor allem nicht bei kleinen fiesen Transaktionen im KB Bereich, die auch heute noch, bei den Meisten mehr als alltäglich sind. ๐
Gruss Alex
1erst dann anfangen nach oben zu klettern, wenn eine bestimmte Lastgrenze überschritten wird
Das hat aber dann nur teilweise mit dem Switch an sich zu tun.Das passiert in der Regel wenn es am Switchport Speed- oder Duplex Autonegotiation Probleme zwischen den dort angeschlossenen Endgeräten gibt und beide Enden unterschiedliche Parameter negotiaten. Thema "Konfiguration der NIC"...
Dann kommt es an diesem Port prinzipbedingt zu Paket Kollisionen und die Collision Rate steigt dann exponentiell zur Last an diesem Port. Das ist richtig, ist aber immer nur Port bezogen und hat nicht direkt etwas mit der Performance des Switches zu tun solange der keine überbuchte interne ASIC Struktur hat.
Zitat von @MysticFoxDE:
Moin @8585324113,
๐ฎ ... auch noch FCoE ... ๐ฑ ... nein, bitte aufhören, da bekomme ich überall nur furchtbare Krämpfe, vor allem wenn ich an Dinge wie Effizienz und oder Transaktionsperformance denke.
Ja, vor allem die richtige Konfiguration der NIC am anderen Ende, insbesondere wenn diese von einem Windows angesteuert werden, kann alleine schon ein Drama für sich werden. ๐
Und komme mir jetzt bitte nicht mir RDMA. Den selbst mit RDMA, kommst du noch lange nicht an die Effizienz einer nativen Storageanbindung per FC oder SAS heran, vor allem nicht bei kleinen fiesen Transaktionen im KB Bereich, die auch heute noch, bei den Meisten mehr als alltäglich sind. ๐
Gruss Alex
Moin @8585324113,
DCB, FCoE usw...
๐ฎ ... auch noch FCoE ... ๐ฑ ... nein, bitte aufhören, da bekomme ich überall nur furchtbare Krämpfe, vor allem wenn ich an Dinge wie Effizienz und oder Transaktionsperformance denke.
Wenn man vor einem nVidia oder Force10 Switch steht das mit 100/400GBits Ports 5000+ Mpps kann in Nanosekundenbereich, dann hat Linespeed eine ganz neue Bedeutung.
Ja, vor allem die richtige Konfiguration der NIC am anderen Ende, insbesondere wenn diese von einem Windows angesteuert werden, kann alleine schon ein Drama für sich werden. ๐
Und komme mir jetzt bitte nicht mir RDMA. Den selbst mit RDMA, kommst du noch lange nicht an die Effizienz einer nativen Storageanbindung per FC oder SAS heran, vor allem nicht bei kleinen fiesen Transaktionen im KB Bereich, die auch heute noch, bei den Meisten mehr als alltäglich sind. ๐
Gruss Alex
Spätestens bei RDMA war klar, dass du nicht ganz wach bist. wir reden von dem selben Thema?
https://www.chelsio.com/performance-benchmarks/
Moin @aqui,
hier muss ich dir etwas widersprechen.
Die Geschwindigkeitaushandlung erfolgt bei Autonegotation lediglich mithilfe von Fast Link Pulse (FLP) und dieses Verfahren berücksichtigt für die Aushandlung der Geschwindigkeit, überhaupt nicht die Qualität der zugrundeliegenden Verkabelung, sondern handelt lediglich nach den Fähigkeiten der entsprechenden Endgeräte, die bestmögliche Verbindungsgeschwindigkeit aus.
Jedoch, nur weil beide Seiten z.B. 1000BASE-T aushandeln können, bedeutet das noch lange nicht, dass auch die Verkabelung dieser Geschwindigkeit standhält. ๐
Gruss Alex
Das hat aber dann nur teilweise mit dem Switch an sich zu tun.
Das passiert in der Regel wenn es am Switchport Speed- oder Duplex Autonegotiation Probleme zwischen den dort angeschlossenen Endgeräten gibt und beide Enden unterschiedliche Parameter negotiaten. Thema "Konfiguration der NIC"...
Das passiert in der Regel wenn es am Switchport Speed- oder Duplex Autonegotiation Probleme zwischen den dort angeschlossenen Endgeräten gibt und beide Enden unterschiedliche Parameter negotiaten. Thema "Konfiguration der NIC"...
hier muss ich dir etwas widersprechen.
Die Geschwindigkeitaushandlung erfolgt bei Autonegotation lediglich mithilfe von Fast Link Pulse (FLP) und dieses Verfahren berücksichtigt für die Aushandlung der Geschwindigkeit, überhaupt nicht die Qualität der zugrundeliegenden Verkabelung, sondern handelt lediglich nach den Fähigkeiten der entsprechenden Endgeräte, die bestmögliche Verbindungsgeschwindigkeit aus.
Jedoch, nur weil beide Seiten z.B. 1000BASE-T aushandeln können, bedeutet das noch lange nicht, dass auch die Verkabelung dieser Geschwindigkeit standhält. ๐
Gruss Alex
Moin @8585324113,
https://community.spiceworks.com/topic/2328491-with-rdma-higher-cpu-load ...
ja, wir reden vom selben Thema. ๐
Ich finde es übrigens schon lustig und auch traurig zugleich, dass in Verbindung mit =>25G und dessen Performance, meistens nur Media Creation oder Entertainment Workflows genannt werden, den das ist lediglich absolut einfachstes sequentielles Datenschupsen. ๐
Kleiner Tipp, lass mal wenigstens einmal über ein S2D einen Performancetest über die volle Kapazität mit kleinen Blöcken fullrandom laufen, dann siehst du gleich was ich meine. ๐
Gruss Alex
Spätestens bei RDMA war klar, dass du nicht ganz wach bist. wir reden von dem selben Thema?
https://www.chelsio.com/performance-benchmarks/
https://www.chelsio.com/performance-benchmarks/
https://community.spiceworks.com/topic/2328491-with-rdma-higher-cpu-load ...
ja, wir reden vom selben Thema. ๐
Ich finde es übrigens schon lustig und auch traurig zugleich, dass in Verbindung mit =>25G und dessen Performance, meistens nur Media Creation oder Entertainment Workflows genannt werden, den das ist lediglich absolut einfachstes sequentielles Datenschupsen. ๐
Kleiner Tipp, lass mal wenigstens einmal über ein S2D einen Performancetest über die volle Kapazität mit kleinen Blöcken fullrandom laufen, dann siehst du gleich was ich meine. ๐
Gruss Alex
Moin Zusammen,
folgend sind zum Vergleich ein paar Messergebnisse, von neuen, 2 Meter langen und sehr hochwertigen CAT 6A Patchkabeln.
Und genau so müssen die Widerstände von einem guten CAT6A Patchkabel aussehen.
Als, nächstes kommen ein paar Messergebnisse, ebenfalls von 2Meter langen CAT 6A Patchkabeln. Jedoch von einem sagen wir mal etwas günstigerem, aber durchaus auch sehr bekanntem Anbieter.
Gruss Alex
folgend sind zum Vergleich ein paar Messergebnisse, von neuen, 2 Meter langen und sehr hochwertigen CAT 6A Patchkabeln.
Und genau so müssen die Widerstände von einem guten CAT6A Patchkabel aussehen.
Als, nächstes kommen ein paar Messergebnisse, ebenfalls von 2Meter langen CAT 6A Patchkabeln. Jedoch von einem sagen wir mal etwas günstigerem, aber durchaus auch sehr bekanntem Anbieter.
Gruss Alex
Moin Zusammen,
wie versprochen folgen nun zum Vergleich ein paar Messergebnisse, die ebenfalls von nagelneuen und 2 Meter langen CAT 6A Patchkabeln stammen, die ich jüngst erst bei Amazon gekauft habe.
Bitte einfach mal in ruhe mit den zuvor geposteten Ergebnissen vergleichen. ๐
Die Limits die rechts abgebildet sind und öfters überschritten werden, gelten übrigens für die ganze Länge eines Ethernet Channels, sprich für bis zu 100m und nicht nur für ein 2 Meter langes Patchkabel. ๐ญ
Gruss Alex
wie versprochen folgen nun zum Vergleich ein paar Messergebnisse, die ebenfalls von nagelneuen und 2 Meter langen CAT 6A Patchkabeln stammen, die ich jüngst erst bei Amazon gekauft habe.
Bitte einfach mal in ruhe mit den zuvor geposteten Ergebnissen vergleichen. ๐
Die Limits die rechts abgebildet sind und öfters überschritten werden, gelten übrigens für die ganze Länge eines Ethernet Channels, sprich für bis zu 100m und nicht nur für ein 2 Meter langes Patchkabel. ๐ญ
Gruss Alex
Auch hier noch mal der Hinweis auf den SteadyTec RJ45 - ebenfalls IDC Technik und sehr bewährt.
Jedoch nicht nennenswert günstig ๐ณ
Und dann halt möglichst zertifizierte Ware einsetzen. Gibt auch keine 100% Garantie, aber schon recht sicher gestellte Einsatzsicherheit.
Jedoch nicht nennenswert günstig ๐ณ
Und dann halt möglichst zertifizierte Ware einsetzen. Gibt auch keine 100% Garantie, aber schon recht sicher gestellte Einsatzsicherheit.
1
Moin Zusammen,
ich habe ja mal zwischendurch geschrieben, dass man Verkabelungsfehler und oder schlechte Patchkabel, auch grob an den Portcounter von dem einen oder andern Switch erkennen kann.
Folgend ein Beispiel wie sowas z.B. bei einem älteren Aruba Switch aussieht ...
... die Geräte am linken Switch sind übrigens alle mit 100Base-T angebunden (VoIP Telefone).
Die Geräte an dem Mittleren und an dem rechten, sind zu >95% Gigabitfähig, aber nur etwa 70% davon,
sind auch wirklich über 1G verbunden. ๐
Die Permanentlinks wurden bei diesem Kunden schon vor über einem Jahr reklassifiziert und alle die aktuell verwendet werden, sollten eigentlich mindestens CAT5E tauglich sein.
Na ja, bin dieses WE bei diesem Kunden für eine grössere Wartung vor Ort und werde den einen oder anderen Channel mal komplett durchmessen.
Gruss Alex
ich habe ja mal zwischendurch geschrieben, dass man Verkabelungsfehler und oder schlechte Patchkabel, auch grob an den Portcounter von dem einen oder andern Switch erkennen kann.
Folgend ein Beispiel wie sowas z.B. bei einem älteren Aruba Switch aussieht ...
... die Geräte am linken Switch sind übrigens alle mit 100Base-T angebunden (VoIP Telefone).
Die Geräte an dem Mittleren und an dem rechten, sind zu >95% Gigabitfähig, aber nur etwa 70% davon,
sind auch wirklich über 1G verbunden. ๐
Die Permanentlinks wurden bei diesem Kunden schon vor über einem Jahr reklassifiziert und alle die aktuell verwendet werden, sollten eigentlich mindestens CAT5E tauglich sein.
Na ja, bin dieses WE bei diesem Kunden für eine grössere Wartung vor Ort und werde den einen oder anderen Channel mal komplett durchmessen.
Gruss Alex
Moin Zusammen,
vorletztes Wochenende hatte ich einen vor Ort Termin bei einem unserer Kunden, um primär sein Hyper-V Cluster, aber auch Dinge wie Switche und das Security-Gateway auf den neusten Stand zu patchen.
Nachdem ich am Sonntagabend mit dem Gröbsten durch war, habe ich um zu prüfen ob alles gut gelaufen ist, vom Hotel aus mitunter auch ein Vollbackup von einem kleinen Server kurz angeschmissen und ging kurz los, um einen frischen Kaffee an der Hotelbar zu organisieren. Als ich wieder zurückkam erwartete mich ein kleiner Schock, den das Backup lief mit 15-20 MB/s immer noch. ๐ฌ
Nachdem ich auf den Hyper-V’s auch einen Haufen Microsoft Updates eingespielt habe, dachte ich als erstes, dass diese schon wieder irgendetwas zerschossen haben. Ein Blick auf den Status der Backup-NAS, befreite Microsoft jedoch als Schuldigen. Den diese lief Netzwerktechnisch nur noch mit 100 Mbit/s. ๐ญ
Folgend der Bericht über die entsprechende Sicherung.
Nach einer kurzen Abstimmung mit dem Admin, beschlossen wir dem Problem am nächsten Tag nachzugehen, da ansonsten alle anderen Systeme, nach einer Umfangreichen Prüfung keinerlei Probleme zeigten.
Angekommen beim Kunden, habe ich am nächsten Morgen als erstes die Leitung durchgemessen, an der die NAS hing.
Folgend das Ergebnis:
๐คข๐คฎ
Der Fluke hätte übrigens den Channel gar nicht als fehlerhaft ausgespuckt, wenn ich nicht explizit auch eine +PoE Messung gemacht hätte, was jedoch bei der Verbindung zum NAS eigentlich vollkommen irrelevant ist.
Also habe ich mir ein paar neue Patchkabel geschnappt, die ich zuvor einzeln noch geprüft habe und habe mit diesen alle drei Patchkabel ersetzt, die zwischen dem NAS und dem Switch bisher im Einsatz waren und habe den Channel danach neu durchgemessen.
๐
Dann habe ich nochmals das Backup von demselben Server angeschmissen, welches am Tag zuvor noch knapp über 20 Minuten gebraucht hat und siehe da …
… nun flutschte es wieder so wie es sein sollte.
Als nächstes sind wir mit dem Admin bei dem Geschäftsführer vorbeigeschlappt und haben dessen Netzwerkanschluss mal kurz durchgemessen, weil auch dieser sich in letzter Zeit über diverseste Probleme beklagt hat.
๐ฑ๐คฎ๐คฎ๐คฎ, sprich, wieder losflitzen und neue passende Patchkabel organisieren und gegen die alten tauschen. ๐ญ
Für den Rest, haben wir einen Folgetermin, der nur diesen elenden Patchkabeln gilt, vereinbart. ๐
Gruss Alex
vorletztes Wochenende hatte ich einen vor Ort Termin bei einem unserer Kunden, um primär sein Hyper-V Cluster, aber auch Dinge wie Switche und das Security-Gateway auf den neusten Stand zu patchen.
Nachdem ich am Sonntagabend mit dem Gröbsten durch war, habe ich um zu prüfen ob alles gut gelaufen ist, vom Hotel aus mitunter auch ein Vollbackup von einem kleinen Server kurz angeschmissen und ging kurz los, um einen frischen Kaffee an der Hotelbar zu organisieren. Als ich wieder zurückkam erwartete mich ein kleiner Schock, den das Backup lief mit 15-20 MB/s immer noch. ๐ฌ
Nachdem ich auf den Hyper-V’s auch einen Haufen Microsoft Updates eingespielt habe, dachte ich als erstes, dass diese schon wieder irgendetwas zerschossen haben. Ein Blick auf den Status der Backup-NAS, befreite Microsoft jedoch als Schuldigen. Den diese lief Netzwerktechnisch nur noch mit 100 Mbit/s. ๐ญ
Folgend der Bericht über die entsprechende Sicherung.
Nach einer kurzen Abstimmung mit dem Admin, beschlossen wir dem Problem am nächsten Tag nachzugehen, da ansonsten alle anderen Systeme, nach einer Umfangreichen Prüfung keinerlei Probleme zeigten.
Angekommen beim Kunden, habe ich am nächsten Morgen als erstes die Leitung durchgemessen, an der die NAS hing.
Folgend das Ergebnis:
๐คข๐คฎ
Der Fluke hätte übrigens den Channel gar nicht als fehlerhaft ausgespuckt, wenn ich nicht explizit auch eine +PoE Messung gemacht hätte, was jedoch bei der Verbindung zum NAS eigentlich vollkommen irrelevant ist.
Also habe ich mir ein paar neue Patchkabel geschnappt, die ich zuvor einzeln noch geprüft habe und habe mit diesen alle drei Patchkabel ersetzt, die zwischen dem NAS und dem Switch bisher im Einsatz waren und habe den Channel danach neu durchgemessen.
๐
Dann habe ich nochmals das Backup von demselben Server angeschmissen, welches am Tag zuvor noch knapp über 20 Minuten gebraucht hat und siehe da …
… nun flutschte es wieder so wie es sein sollte.
Als nächstes sind wir mit dem Admin bei dem Geschäftsführer vorbeigeschlappt und haben dessen Netzwerkanschluss mal kurz durchgemessen, weil auch dieser sich in letzter Zeit über diverseste Probleme beklagt hat.
๐ฑ๐คฎ๐คฎ๐คฎ, sprich, wieder losflitzen und neue passende Patchkabel organisieren und gegen die alten tauschen. ๐ญ
Für den Rest, haben wir einen Folgetermin, der nur diesen elenden Patchkabeln gilt, vereinbart. ๐
Gruss Alex
1
Frage: Warum nicht gleich Patchkabel dabei gehabt? Wäre proaktiv gewesen. Okay, möglicherweise stellt sich die Frage welchen Längen man dabei haben sollte.
Trotzdem sehr guter Bericht ๐๐
Gruss Penny.
Trotzdem sehr guter Bericht ๐๐
Gruss Penny.
2
Moin Penny,
das ist nicht ganz so einfach.
Zum einen kommt das Problem mit den unterschiedlichen Längen.
Dann hat jeder Kunde seine eigenen Vorlieben was die Farben angeht.
In diesem Fall hat der Kunde z.B. alle neuen Patchkabel in gelb und wir hatten wiederum noch nie gelbe Patchkabel im Bestand.
Dann bevorzugt der eine Kunde den einen Hersteller und der andere einen anderen
und der Einkauf möchte die Kabel eh am liebsten bei Amazon bestellen, weil die dort viel billiger sind und auf
der Verpackung ja eh dasselbe drauf steht, wie bei den teureren, u.s.w..
Ausserdem möchte ich mich wegen der Problematik, die sich mit unter bei den meisten Patchkabeln abzuzeichnen scheint, der extrem vorzeitigen Alterung, aktuell nicht mehr wirklich in deren Lieferkette mit dazwischenschieben.
Danke!
Gruss Alex
Frage: Warum nicht gleich Patchkabel dabei gehabt? Wäre proaktiv gewesen. Okay, möglicherweise stellt sich die Frage welchen Längen man dabei haben sollte.
das ist nicht ganz so einfach.
Zum einen kommt das Problem mit den unterschiedlichen Längen.
Dann hat jeder Kunde seine eigenen Vorlieben was die Farben angeht.
In diesem Fall hat der Kunde z.B. alle neuen Patchkabel in gelb und wir hatten wiederum noch nie gelbe Patchkabel im Bestand.
Dann bevorzugt der eine Kunde den einen Hersteller und der andere einen anderen
und der Einkauf möchte die Kabel eh am liebsten bei Amazon bestellen, weil die dort viel billiger sind und auf
der Verpackung ja eh dasselbe drauf steht, wie bei den teureren, u.s.w..
Ausserdem möchte ich mich wegen der Problematik, die sich mit unter bei den meisten Patchkabeln abzuzeichnen scheint, der extrem vorzeitigen Alterung, aktuell nicht mehr wirklich in deren Lieferkette mit dazwischenschieben.
Trotzdem sehr guter Bericht ๐๐
Danke!
Gruss Alex
Hatte die Tage auch wieder einen Fall mit den gesplitterten Patchkabel-Köpfen. Kunde hat mehrfach bemerkt, dass das gesamte Netzwerk zusammenbricht. So hart, dass alle Netzwerkgeräte (Switche, Accesspoint, usw.) aus der Verwaltung fliegen und diese nicht mal mehr erreichbar ist.
Das Problem begann immer nachts beim duplizieren der Sicherungen. Auf den ersten Blick schien auch alles okay, Server GBIT, NAS GBIT, Switche untereinander okay. Habe dann die Duplizierung manuell angestoßen und keine Minute später war das gesamte Netzwerk down. Patchkabel vom NAS gezogen und zack läuft es wieder.
Meine beste Vermutung ist, dass das NAS absoluten Datenmüll ins Netzwerk gesendet hat und die Switche sich den gegenseitig hin und hergeschoben haben weil die damit nix anfangen konnten. Im Monitoring zeigt sich das dann wie folgt:
Jetzt ist ein neues Kabel dran und der Spuck ist vorbei.
Der Knüller ist, dass nur die Links zwischen den Switchen mit Paketen ausrasten. Der Port vom NAS ist im Monitoring unauffällig! Das hatte ich schon mal vor Jahren in einem anderen Netzwerk und konnte den Fehler einfach nicht finden ...
Das Problem begann immer nachts beim duplizieren der Sicherungen. Auf den ersten Blick schien auch alles okay, Server GBIT, NAS GBIT, Switche untereinander okay. Habe dann die Duplizierung manuell angestoßen und keine Minute später war das gesamte Netzwerk down. Patchkabel vom NAS gezogen und zack läuft es wieder.
Meine beste Vermutung ist, dass das NAS absoluten Datenmüll ins Netzwerk gesendet hat und die Switche sich den gegenseitig hin und hergeschoben haben weil die damit nix anfangen konnten. Im Monitoring zeigt sich das dann wie folgt:
Jetzt ist ein neues Kabel dran und der Spuck ist vorbei.
Der Knüller ist, dass nur die Links zwischen den Switchen mit Paketen ausrasten. Der Port vom NAS ist im Monitoring unauffällig! Das hatte ich schon mal vor Jahren in einem anderen Netzwerk und konnte den Fehler einfach nicht finden ...
Moin @anteNope,
kannst die gerne für eine Feinanalyse mal auch rüberschicken. ๐
Das sieht für mich eher danach aus, als ob die Switche aufgrund von zu vielen Übertragungsfehler, ständig die Ports reseten.
๐ฏ ... das hört sich aber etwas schräg an.
Wie sind die Switche untereinander verbunden CU oder LWL?
Gruss Alex
Hatte die Tage auch wieder einen Fall mit den gesplitterten Patchkabel-Köpfen. Kunde hat mehrfach bemerkt, dass das gesamte Netzwerk zusammenbricht. So hart, dass alle Netzwerkgeräte (Switche, Accesspoint, usw.) aus der Verwaltung fliegen und diese nicht mal mehr erreichbar ist.
kannst die gerne für eine Feinanalyse mal auch rüberschicken. ๐
Meine beste Vermutung ist, dass das NAS absoluten Datenmüll ins Netzwerk gesendet hat und die Switche sich den gegenseitig hin und hergeschoben haben weil die damit nix anfangen konnten. Im Monitoring zeigt sich das dann wie folgt:
Das sieht für mich eher danach aus, als ob die Switche aufgrund von zu vielen Übertragungsfehler, ständig die Ports reseten.
Der Knüller ist, dass nur die Links zwischen den Switchen mit Paketen ausrasten. Der Port vom NAS ist im Monitoring unauffällig! Das hatte ich schon mal vor Jahren und konnte den Fehler einfach nicht finden ...
๐ฏ ... das hört sich aber etwas schräg an.
Wie sind die Switche untereinander verbunden CU oder LWL?
Gruss Alex
๐ฏ ... das hört sich aber etwas schräg an.
Wie sind die Switche untereinander verbunden CU oder LWL?
Wie sind die Switche untereinander verbunden CU oder LWL?
CAT6A. GBIT-Uplink. Kleines Netzwerk. 1x UDM-Pro, 1x USW-24, 1x USW-48, 5x ACs.
kannst die gerne für eine Feinanalyse mal auch rüberschicken. ๐
Bisher habe ich nun zwei gesplitterte gesammelt ๐
Moin Zusammen,
noch ein kleiner Nachtrag.
Letzten Freitag war ich ungeplant bei einem kleineren Kunden, nachdem bei diesem am Tag zuvor sein Sophos XGS-Cluster abgeraucht ist. ๐ฌ
Warum sich das XGS Cluster von heute auf morgen auf Werkseinstellungen zurückgesetzt hat, habe ich nicht rausfinden können, dank einer aktuellen Sicherung, war das Problem jedoch relativ schnell behoben.
Beim Gehen entdeckte ich bei dem Kunden einen Karton nagelneuer CAT.7 Patchkabel von KIBETA und habe darauf den Admin sofort gefragt, ob ich nicht eins davon mitnehmen könnte. Er sagte "natürlich" und so wanderte eins davon in meine Tasche.
Gerade eben habe ich es widerentdeckt und natürlich sofort den Fluke damit gefüttert. ๐คช
Doch leider hat dieses Patchkabel, noch nicht mal einen Class D, sprich, CAT5E Test bestanden. ๐ญ
Dabei wurden von diesem Patchkabel Grenzwerte überschritten, die für die Länge des gesamten Channels, also von bis zu 100m gelten und nicht nur für die Länge von 3m! ๐
๐
Gruss Alex
noch ein kleiner Nachtrag.
Letzten Freitag war ich ungeplant bei einem kleineren Kunden, nachdem bei diesem am Tag zuvor sein Sophos XGS-Cluster abgeraucht ist. ๐ฌ
Warum sich das XGS Cluster von heute auf morgen auf Werkseinstellungen zurückgesetzt hat, habe ich nicht rausfinden können, dank einer aktuellen Sicherung, war das Problem jedoch relativ schnell behoben.
Beim Gehen entdeckte ich bei dem Kunden einen Karton nagelneuer CAT.7 Patchkabel von KIBETA und habe darauf den Admin sofort gefragt, ob ich nicht eins davon mitnehmen könnte. Er sagte "natürlich" und so wanderte eins davon in meine Tasche.
Gerade eben habe ich es widerentdeckt und natürlich sofort den Fluke damit gefüttert. ๐คช
Doch leider hat dieses Patchkabel, noch nicht mal einen Class D, sprich, CAT5E Test bestanden. ๐ญ
Dabei wurden von diesem Patchkabel Grenzwerte überschritten, die für die Länge des gesamten Channels, also von bis zu 100m gelten und nicht nur für die Länge von 3m! ๐
๐
Gruss Alex
Moin @anteNope,
hast du auch schon das Patchkabel zwischen den Switchen getauscht?
Bei dem Beispiel mit dem NAS welches ich heute gepostet habe, war am Ende des Tages ein nur 0,5 Meter langes Patchkabel zwischen zwei Patchfeldern der Hauptübeltäter. ๐ญ
Gruss Alex
CAT6A. GBIT-Uplink. Kleines Netzwerk. 1x UDM-Pro, 1x USW-24, 1x USW-48, 5x ACs.
hast du auch schon das Patchkabel zwischen den Switchen getauscht?
Bei dem Beispiel mit dem NAS welches ich heute gepostet habe, war am Ende des Tages ein nur 0,5 Meter langes Patchkabel zwischen zwei Patchfeldern der Hauptübeltäter. ๐ญ
Gruss Alex
hast du auch schon das Patchkabel zwischen den Switchen getauscht?
Schon vorher. Sobald man das NAS abgezogen hat, lief das Netzwerk Sekunden später wieder normal. ¯\_(ใ)_/¯
Moin @anteNope,
OK, dann kann es eigentlich nur noch einen Grund geben und zwar einen Pufferüberlauf am Switch der an der NAS hängt. Das würde auch erklären, weshalb andere Geräte betroffen sind.
An diesem Problem ist aber Microsoft nicht ganz unschuldig.
Den die haben ihren Betriebssystemen schon seit längerem beigebracht, eine TCP Sessions mit einer Grösse von bis zu !! 1GByte !! zu öffnen. ๐คฎ๐คฎ๐คฎ
Mit dem folgenden Befehl ...
... kann man die Grösse der TCP-Session bei einem Windows wieder auf 64K einschränken.
Es kann zwar sein, dass dadurch die Bandbreite etwas reduziert wird, dafür linderst du damit extrem die Gefahr einer Pufferüberflutung deiner Netzwerkkomponenten. ๐
By the Way, dieser Befehl bewirkt nicht nur bei diesem Problem wahre Wunder, sondern auch bei SQL Server, DC's, Applikationsserver, Session-Hosts u.s.w.. Denn so gut wie KEINE Enterprise Anwendung, profitiert wirklich von einer 1GByte grossen TCP-Session!
Ferner kannst du auch mit Flow-Control einem solchen Problem aktiv entgegenwirken.
Aber Vorsicht, Flow-Control muss bei allen Komponenten durchgängig aktiv sein, damit man sich am Ende des Tages damit nicht noch zusätzlich ins Knie schiesst!
Gruss Alex
Schon vorher. Sobald man das NAS abgezogen hat, lief das Netzwerk Sekunden später wieder normal. ¯\_(ใ)_/¯
OK, dann kann es eigentlich nur noch einen Grund geben und zwar einen Pufferüberlauf am Switch der an der NAS hängt. Das würde auch erklären, weshalb andere Geräte betroffen sind.
An diesem Problem ist aber Microsoft nicht ganz unschuldig.
Den die haben ihren Betriebssystemen schon seit längerem beigebracht, eine TCP Sessions mit einer Grösse von bis zu !! 1GByte !! zu öffnen. ๐คฎ๐คฎ๐คฎ
Mit dem folgenden Befehl ...
netsh int tcp set global autotuninglevel=disabledEs kann zwar sein, dass dadurch die Bandbreite etwas reduziert wird, dafür linderst du damit extrem die Gefahr einer Pufferüberflutung deiner Netzwerkkomponenten. ๐
By the Way, dieser Befehl bewirkt nicht nur bei diesem Problem wahre Wunder, sondern auch bei SQL Server, DC's, Applikationsserver, Session-Hosts u.s.w.. Denn so gut wie KEINE Enterprise Anwendung, profitiert wirklich von einer 1GByte grossen TCP-Session!
Ferner kannst du auch mit Flow-Control einem solchen Problem aktiv entgegenwirken.
Aber Vorsicht, Flow-Control muss bei allen Komponenten durchgängig aktiv sein, damit man sich am Ende des Tages damit nicht noch zusätzlich ins Knie schiesst!
Gruss Alex
1und natürlich sofort den Fluke damit gefüttert.
ich will einen Fluke!! 
Viele Grüße, commodity
2
Bald ist Weihnachten...
Gruss Penny.
Gruss Penny.
Moin @commodity,
Die Aktion ist gerade bei mir als Newsletter eingetrudelt.
https://www.dmn-solutions.com/promos/fluke-10-jahre-versiv/
๐
Gruss Alex
ich will einen Fluke!!
Die Aktion ist gerade bei mir als Newsletter eingetrudelt.
https://www.dmn-solutions.com/promos/fluke-10-jahre-versiv/
๐
Gruss Alex
1Aber Vorsicht, Flow-Control muss bei allen Komponenten durchgängig aktiv sein, damit man sich am Ende des Tages damit nicht noch zusätzlich ins Knie schiesst!
Deshalb macht man das auch niemals im Netzwerk und überlässt es immer den Endgeräten. Allein schon die Tatsache das die Buffer bei allen Herstellern gravierend unterschiedlich und auch häufig gar nicht (Cut Through Switches) vorhanden sind, macht einen solchen Knieschuss fast immer unvermeidlich wenn man sowas versucht umzusetzen.
Moin @aqui,
ähm, Flow Control kann nur richtig funktionieren, wenn es sowohl auf den Endgeräten, als auch auf sämtlichen Switchen dazwischen, sauber aktiviert ist.
Wenn das nicht der Fall ist, dann schiesst man sich mit den durch das Flow-Control zusätzlich generierten Pause-Frames, meistens nur noch mehr ins Knie. ๐
Gruss Alex
Deshalb macht man das auch niemals im Netzwerk und überlässt es immer den Endgeräten.
ähm, Flow Control kann nur richtig funktionieren, wenn es sowohl auf den Endgeräten, als auch auf sämtlichen Switchen dazwischen, sauber aktiviert ist.
Wenn das nicht der Fall ist, dann schiesst man sich mit den durch das Flow-Control zusätzlich generierten Pause-Frames, meistens nur noch mehr ins Knie. ๐
Gruss Alex
1Zitat von @MysticFoxDE:
ähm, Flow Control kann nur richtig funktionieren, wenn es sowohl auf den Endgeräten, als auch auf sämtlichen Switchen dazwischen, sauber aktiviert ist.
Wenn das nicht der Fall ist, dann schiesst man sich mit den durch das Flow-Control zusätzlich generierten Pause-Frames, meistens nur noch mehr ins Knie. ๐
ähm, Flow Control kann nur richtig funktionieren, wenn es sowohl auf den Endgeräten, als auch auf sämtlichen Switchen dazwischen, sauber aktiviert ist.
Wenn das nicht der Fall ist, dann schiesst man sich mit den durch das Flow-Control zusätzlich generierten Pause-Frames, meistens nur noch mehr ins Knie. ๐
Die Information hätte ich gerne vor 7 Jahren gehabt. War die absolute Katastrophe und keiner konnte einem dabei helfen ๐ฅ Aber so ist das halt wenn der Kunde fröhlich irgendwelche Geräte mit irgendwelchen Kabeln in die total verdreckten, verrosteten CAT5 Dosen stöpselt ... Dann stochert man sprichwörtlich im Sand und nunja ¯\_(ใ)_/¯
Moin @anteNope,
wie ich schon gesagt habe, mit Flow-Control muss man sehr vorsichtig umgehen!
Je nach Delayed ACK, Congestion Control und diversen anderen Einstellungen, kann dieses ratz fatz auch ein Haufen TCP Session Resets verursachen. ๐
Gruss Alex
Die Information hätte ich gerne vor 7 Jahren gehabt. War die absolute Katastrophe und keiner konnte einem dabei helfen ๐ฅ Aber so ist das halt wenn der Kunde fröhlich irgendwelche Geräte mit irgendwelchen Kabeln in die total verdreckten, verrosteten CAT5 Dosen stöpselt ... Dann stochert man sprichwörtlich im Sand und nunja ¯\_(ใ)_/¯
wie ich schon gesagt habe, mit Flow-Control muss man sehr vorsichtig umgehen!
Je nach Delayed ACK, Congestion Control und diversen anderen Einstellungen, kann dieses ratz fatz auch ein Haufen TCP Session Resets verursachen. ๐
Gruss Alex
Series: NETZWERKVERKABELUNG DIE HORROR STORRY
NVDHS - SESSION 002 - EPISODE 01 - Patchkabel - Das Widerstand-Desaster! (german)52NVDHS - SESSION 001 - Installation Netzwerkdosen - So bitte nicht! (german)14