Netzwerkdrucker druckt an einem Switch langsam - an einem anderen schnell

[Michael Landenberger]

Hallo,

von folgendem Phänomen wüsste ich gerne die Ursache.

Gegeben seien folgende Szenarien, wobei alle Verbindungen über
Ethernet-Leitung laufen (kein WLAN im Spiel):

1. Computer und Drucker direkt am Router (Fritzbox) -> Drucker druckt
Druckaufträge vom Computer schnell

2. Computer und Drucker an einem Switch (TP-Link TL-SG105) und dieser an der
Fritzbox -> Drucker druckt Druckaufträge (auch reine Textdrucke) vom Computer
extrem langsam. Verbindung über den gleichen Switch vom Computer zu anderen
Clients im Netzwerk ist aber schnell

3. Wie 2., nur dass ein anderer Switch (Netgear ProSafe GS108) zum Einsatz
kommt -> Drucker druckt Druckaufträge vom Computer schnell

Am Drucker sind 100 MBit/s Vollduplex fest eingestellt. Warum funktioniert das
in Situation 1 und 3, aber nicht in 2?

JFTR: in 2. geht das Drucken so langsam, dass es auch nicht mit einem Rückfall
der Ethernet-Verbindung auf 10 MBit/s erklärbar ist. Gefühlt sind da 0,01
MBit/s am Werkeln. Wechsel der Ports am Switch hat nichts gebracht.

Gruß

Michael

[Marc Haber]

Post by Michael Landenberger
2. Computer und Drucker an einem Switch (TP-Link TL-SG105) und dieser an der
Fritzbox -> Drucker druckt Druckaufträge (auch reine Textdrucke) vom Computer
extrem langsam. Verbindung über den gleichen Switch vom Computer zu anderen
Clients im Netzwerk ist aber schnell
3. Wie 2., nur dass ein anderer Switch (Netgear ProSafe GS108) zum Einsatz
kommt -> Drucker druckt Druckaufträge vom Computer schnell
Am Drucker sind 100 MBit/s Vollduplex fest eingestellt. Warum funktioniert das
in Situation 1 und 3, aber nicht in 2?

Netzwerkeranfängerfehler Nummer Eins: Ein provozierter Duplexmismatch.

Stell den Drucker auf autonegotiation und probier es nochmal. Der
nicht managebare Switch macht Autonegotiation. Das feste einstellen am
Drucker schaltet autonegotition aus und der Switch macht dann das
einzige was er tun kann, er fällt auf den Default zurück und das ist
oft 100 Mbit/s Halbduplex, d.h. jedes vom Drucker zurückgeschickte
ACK-Paket ist für den Switch eine Kollision.

Grüße
Marc

[Michael Landenberger]

Post by Marc Haber
Netzwerkeranfängerfehler Nummer Eins: Ein provozierter Duplexmismatch.
Stell den Drucker auf autonegotiation und probier es nochmal.

Danke für den Tipp.

Der Drucker steht aber genau deswegen auf 100 MBit/s fullduplex, weil das mit
der Autonegotiation mal nicht geklappt hat. Erst die feste Einstellung ließ
den Drucker mit normaler Geschwindigkeit drucken. Ansonsten wäre ich nie auf
die Idee gekommen, am Drucker eine feste Geschwindigkeit einzustellen.

Post by Marc Haber
Das feste einstellen am
Drucker schaltet autonegotition aus und der Switch macht dann das
einzige was er tun kann, er fällt auf den Default zurück und das ist
oft 100 Mbit/s Halbduplex, d.h. jedes vom Drucker zurückgeschickte
ACK-Paket ist für den Switch eine Kollision.

Ich denke, dass der Switch dann sogar auf 10 MBit/s halbduplex zurückfällt.

Aber warum funktioniert es nur mit dem TP-Link-Switch nicht, mit dem
Netgear-Switch und mit der Fritzbox aber schon?

Gruß

Michael

[Marco Moock]

Post by Michael Landenberger

Post by Marc Haber
Netzwerkeranfängerfehler Nummer Eins: Ein provozierter
Duplexmismatch.
Stell den Drucker auf autonegotiation und probier es nochmal.

Danke für den Tipp.
Der Drucker steht aber genau deswegen auf 100 MBit/s fullduplex, weil
das mit der Autonegotiation mal nicht geklappt hat.

Dann muss man das angehen.

Post by Michael Landenberger
Erst die feste Einstellung ließ den Drucker mit normaler
Geschwindigkeit drucken.

Da bei Duplex mismatch Pakete als Kollision erkannt werden (die keine
ist) und dann verworfen werden, kommt es dir langsam vor. TCP hat einen
Mechanismus, um eine erfolgreiche Zustellung zu erkennen.
Ein Duplex-Mismatch ist immer Pfusch und muss beseitigt werden.

Post by Michael Landenberger

Post by Marc Haber
Das feste einstellen am
Drucker schaltet autonegotition aus und der Switch macht dann das
einzige was er tun kann, er fällt auf den Default zurück und das ist
oft 100 Mbit/s Halbduplex, d.h. jedes vom Drucker zurückgeschickte
ACK-Paket ist für den Switch eine Kollision.

Ich denke, dass der Switch dann sogar auf 10 MBit/s halbduplex
zurückfällt.

Muss geprüft werden.

Post by Michael Landenberger
Aber warum funktioniert es nur mit dem TP-Link-Switch nicht, mit dem
Netgear-Switch und mit der Fritzbox aber schon?

Weil der ggf. ne Macke hat.

[Michael Landenberger]

Post by Marco Moock

Post by Michael Landenberger
Der Drucker steht aber genau deswegen auf 100 MBit/s fullduplex, weil
das mit der Autonegotiation mal nicht geklappt hat.

Dann muss man das angehen.

Das ist längst angegangen worden. Die Umstellung erfolgte zu einer Zeit, als
der Drucker an einem völlig anderen Gerät angeschlossen war, das heute gar
nicht mehr im Einsatz ist (AFAIR eine O2 Home Box). Ich habe nur vergessen,
das rückgängig zu machen, als ich den Drucker anders angeschlossen habe. Da er
zunächst normal funktioniert hat, gab es auch nichts, was mich daran erinnert
hat.

Post by Marco Moock

Post by Michael Landenberger
Aber warum funktioniert es nur mit dem TP-Link-Switch nicht, mit dem
Netgear-Switch und mit der Fritzbox aber schon?

Weil der ggf. ne Macke hat.

Oder weil er sich schlicht anders verhält als die anderen Geräte, die bei
fehlgeschlagener Autonegotiation eine Einstellung wählen, die zufällig zu der
des Druckers passt. Der TP-Link-Switch wählt dagegen in diesem Fall eine
Einstellung, die nicht passt.

Im Moment ist der Drucker an der Fritzbox angeschlossen, die
Ethernet-Schnittstelle ist auf "Auto" eingestellt. Der Drucker funktioniert
normal. Das tat er zumindest an der Fritzbox aber auch mit fester Einstellung
auf 100 MBit/s Vollduplex.

Gruß

Michael

[Marc Haber]

Post by Michael Landenberger

Post by Marc Haber
Netzwerkeranfängerfehler Nummer Eins: Ein provozierter Duplexmismatch.
Stell den Drucker auf autonegotiation und probier es nochmal.

Danke für den Tipp.
Der Drucker steht aber genau deswegen auf 100 MBit/s fullduplex, weil das mit
der Autonegotiation mal nicht geklappt hat. Erst die feste Einstellung ließ
den Drucker mit normaler Geschwindigkeit drucken. Ansonsten wäre ich nie auf
die Idee gekommen, am Drucker eine feste Geschwindigkeit einzustellen.

Stell ihn mal auf 100 Half.

Post by Michael Landenberger

Post by Marc Haber
Das feste einstellen am
Drucker schaltet autonegotition aus und der Switch macht dann das
einzige was er tun kann, er fällt auf den Default zurück und das ist
oft 100 Mbit/s Halbduplex, d.h. jedes vom Drucker zurückgeschickte
ACK-Paket ist für den Switch eine Kollision.

Ich denke, dass der Switch dann sogar auf 10 MBit/s halbduplex zurückfällt.

Auch das kann passieren. Unter anderem deswegen sind nicht managebare
Switches eigentlich immer Flickwerk.

Post by Michael Landenberger
Aber warum funktioniert es nur mit dem TP-Link-Switch nicht, mit dem
Netgear-Switch und mit der Fritzbox aber schon?

Weil es gerade im Billigsegment immer mal unterschiedlich
standardwidriges Verhalten geben kann. Da kann man dann nix anderes
mehr tun als so lange Komponenten zu tauschen bis es zufällig mal
funktioniert.

Grüße
Marc

[Gerrit Heitsch]

Post by Michael Landenberger
Aber warum funktioniert es nur mit dem TP-Link-Switch nicht, mit dem
Netgear-Switch und mit der Fritzbox aber schon?

Der TP-Link Switch verhält sich korrekt. Wenn die Gegenseite keine
Autonegotiation anbietet ist das ein Hub und der kann nur Halbduplex
womit sich ein Duplex-Mismatch ergibt und die Verbindung sehr langsam wird.

Die Frage sollte also eher heissen, warum es mit Fritzbox oder Netgear
funktioniert hat.

Gerrit

[Marco Moock]

Post by Gerrit Heitsch
Der TP-Link Switch verhält sich korrekt. Wenn die Gegenseite keine
Autonegotiation anbietet ist das ein Hub und der kann nur Halbduplex
womit sich ein Duplex-Mismatch ergibt und die Verbindung sehr langsam wird.

Langsam ist hier der falsche Begriff. Wenn gleichzeitig gesendet wird
auf beiden Seiten werden diese Frames verworfen.
Eine Kommunikation ist dann nicht mehr sinnvoll möglich.

[Gerrit Heitsch]

Post by Marco Moock

Post by Gerrit Heitsch
Der TP-Link Switch verhält sich korrekt. Wenn die Gegenseite keine
Autonegotiation anbietet ist das ein Hub und der kann nur Halbduplex
womit sich ein Duplex-Mismatch ergibt und die Verbindung sehr langsam wird.

Langsam ist hier der falsche Begriff. Wenn gleichzeitig gesendet wird
auf beiden Seiten werden diese Frames verworfen.
Eine Kommunikation ist dann nicht mehr sinnvoll möglich.

Ja, aber üblicherweise bekommt man noch Kommunikation hin, wenn auch
sehr langsam. Mit Glück so 500KB/sec max.

Gerrit

[Marc Haber]

Post by Marco Moock

Post by Gerrit Heitsch
Der TP-Link Switch verhält sich korrekt. Wenn die Gegenseite keine
Autonegotiation anbietet ist das ein Hub und der kann nur Halbduplex
womit sich ein Duplex-Mismatch ergibt und die Verbindung sehr langsam wird.

Langsam ist hier der falsche Begriff. Wenn gleichzeitig gesendet wird
auf beiden Seiten werden diese Frames verworfen.
Eine Kommunikation ist dann nicht mehr sinnvoll möglich.

TCP tritt dann weit genug zurück dass es trotzdem noch ein wenig
funktioniert. Probiers einfach mal aus.

Grüße
Marc

[Marco Moock]

Post by Marc Haber

Post by Marco Moock

Post by Gerrit Heitsch
Der TP-Link Switch verhält sich korrekt. Wenn die Gegenseite keine
Autonegotiation anbietet ist das ein Hub und der kann nur
Halbduplex womit sich ein Duplex-Mismatch ergibt und die
Verbindung sehr langsam wird.

Langsam ist hier der falsche Begriff. Wenn gleichzeitig gesendet wird
auf beiden Seiten werden diese Frames verworfen.
Eine Kommunikation ist dann nicht mehr sinnvoll möglich.

TCP tritt dann weit genug zurück dass es trotzdem noch ein wenig
funktioniert. Probiers einfach mal aus.

Wenn man schon soweit ist. Ich denke da gerade an so Fälle, wo DHCP,
IPv6RS/RA eine Kollision erzeugen und dann die IP-Vergabe schon
scheitert. Natürlich nur manchmal.
Auch das ganze Discovery-Geraffel mit Multicast wird mit tollen
Effekten drunter leiden.

[Kay Martinen]

Post by Michael Landenberger

Post by Marc Haber
Netzwerkeranfängerfehler Nummer Eins: Ein provozierter Duplexmismatch.
Stell den Drucker auf autonegotiation und probier es nochmal.

Danke für den Tipp.
Der Drucker steht aber genau deswegen auf 100 MBit/s fullduplex, weil das mit
der Autonegotiation mal nicht geklappt hat. Erst die feste Einstellung ließ
den Drucker mit normaler Geschwindigkeit drucken. Ansonsten wäre ich nie auf
die Idee gekommen, am Drucker eine feste Geschwindigkeit einzustellen.

Bist du sicher das dir da kein Defektes Kabel diesen Eindruck vermittelt
hatte?

Post by Michael Landenberger

Post by Marc Haber
Das feste einstellen am
Drucker schaltet autonegotition aus und der Switch macht dann das
einzige was er tun kann, er fällt auf den Default zurück und das ist
oft 100 Mbit/s Halbduplex, d.h. jedes vom Drucker zurückgeschickte
ACK-Paket ist für den Switch eine Kollision.

Ich denke, dass der Switch dann sogar auf 10 MBit/s halbduplex zurückfällt.
Aber warum funktioniert es nur mit dem TP-Link-Switch nicht, mit dem
Netgear-Switch und mit der Fritzbox aber schon?

Bist du SICHER das es sich um einen TL-SG105 handelt? Und nicht etwa um
einen TL-SG105E? Letzterer ist ein WebSmart Switch der entweder mit
einem Windows (JAR, geht auch unter Linux) Tool oder bei neueren
Revisionen mit einer Eingebauten WebUI konfiguriert werden kann.

Dort gibt es für jeden Port auch einstellungen zur Datenrate und
Halb/Vollduplex die man setzen kann. Wenn du den NICHT neu kauftest oder
er schlichtweg nicht auf Auto eingestellt war dann könnte dies deine
Probleme ebenfalls erklären.

Es bleibt dann aber immer noch ein Mismatch den du dann beheben
müsstest. Nur böte sich die WebUI des Switch hier noch als Möglichkeit an.

Bye/
/Kay

[Michael Landenberger]

Post by Kay Martinen
Bist du SICHER das es sich um einen TL-SG105 handelt? Und nicht etwa um
einen TL-SG105E?

Ganz sicher. Es ist ein TL-SG105 (ohne "E").

Gruß

Michael

[Gerrit Heitsch]

Post by Michael Landenberger
Am Drucker sind 100 MBit/s Vollduplex fest eingestellt. Warum funktioniert das
in Situation 1 und 3, aber nicht in 2?

Das ist ein Fehler. Darf man nur machen wenn man den Drucker so
einstellt, daß er weiterhin Autonegotiation macht aber dann nur 100FDX
als Geschwindigkeit anbietet. Wenn man Autonegotiation vollständig
abschaltet muss man auf 100 Halbduplex stellen weil das das ist, was ein
Switch annimmt wenn Autonegotiation fehlschlägt.

Post by Michael Landenberger
JFTR: in 2. geht das Drucken so langsam, dass es auch nicht mit einem Rückfall
der Ethernet-Verbindung auf 10 MBit/s erklärbar ist. Gefühlt sind da 0,01
MBit/s am Werkeln. Wechsel der Ports am Switch hat nichts gebracht.

Duplex mismatch, da wird das so langsam.

Also Autonegotiation wieder ein und probieren ob dann alles am
fraglichen Switch funktioniert.

Gerrit

[Marco Moock]

Wenn man Autonegotiation vollständig abschaltet muss man auf 100
Halbduplex stellen weil das das ist, was ein Switch annimmt wenn
Autonegotiation fehlschlägt.

Warum zwingend 100?
Prüft der das anhand des Fast Link Pulse?

[Gerrit Heitsch]

Post by Marco Moock

Wenn man Autonegotiation vollständig abschaltet muss man auf 100
Halbduplex stellen weil das das ist, was ein Switch annimmt wenn
Autonegotiation fehlschlägt.

Warum zwingend 100?
Prüft der das anhand des Fast Link Pulse?

Ja, die Geschwindigkeit kann aus dem Linkbeat abgeleitet werden. So
funktioniert es wenn ein Hub angeschlossen wird.

10Mbit/sec möchte man sich sparen wenn es nicht unbedingt nötig ist,
daher sollte man 100HDX nehmen.

Gerrit

[Kay Martinen]

Post by Gerrit Heitsch

Post by Marco Moock

Wenn man Autonegotiation vollständig abschaltet muss man auf 100
Halbduplex stellen weil das das ist, was ein Switch annimmt wenn
Autonegotiation fehlschlägt.

Warum zwingend 100?
Prüft der das anhand des Fast Link Pulse?

Wie sonst.

Post by Gerrit Heitsch
Ja, die Geschwindigkeit kann aus dem Linkbeat abgeleitet werden. So
funktioniert es wenn ein Hub angeschlossen wird.
10Mbit/sec möchte man sich sparen wenn es nicht unbedingt nötig ist,
daher sollte man 100HDX nehmen.

Ich meine das es den FLP auch erst mit 100BaseT gab. Ein 10MB Hub kann
den nicht senden weshalb der Partner am anderen Ende ja ohne FLP nur
noch auf 10Mbit runter schalten kann.

Es macht aber doch auch keinen Sinn wenn man Autonegotiation an lassen
könnte und das die Geschwindigkeit einstellt aber dann manuell auf Halb
oder Vollduplex stellen könnte. Das sollte eigentlich nicht möglich sein
oder?

Bye/
/Kay

[Gerrit Heitsch]

Post by Kay Martinen

Post by Gerrit Heitsch

Post by Marco Moock

Wenn man Autonegotiation vollständig abschaltet muss man auf 100
Halbduplex stellen weil das das ist, was ein Switch annimmt wenn
Autonegotiation fehlschlägt.

Warum zwingend 100?
Prüft der das anhand des Fast Link Pulse?

Wie sonst.

Post by Gerrit Heitsch
Ja, die Geschwindigkeit kann aus dem Linkbeat abgeleitet werden. So
funktioniert es wenn ein Hub angeschlossen wird.
10Mbit/sec möchte man sich sparen wenn es nicht unbedingt nötig ist,
daher sollte man 100HDX nehmen.

Ich meine das es den FLP auch erst mit 100BaseT gab. Ein 10MB Hub kann
den nicht senden weshalb der Partner am anderen Ende ja ohne FLP nur
noch auf 10Mbit runter schalten kann.
Es macht aber doch auch keinen Sinn wenn man Autonegotiation an lassen
könnte und das die Geschwindigkeit einstellt aber dann manuell auf Halb
oder Vollduplex stellen könnte. Das sollte eigentlich nicht möglich sein
oder?

Doch, geht. Habe ich unter Solaris oft gemacht. Zumindest dort kann man
nicht nur Autonegotiation ein- oder ausschalten, man kann auch
definieren was bei Autonegotiation angeboten wird. Ich kann also
Autonegotiation eingeschaltet lassen, aber nur 100FDX anbieten. Dann
bekomme ich entweder einen 100FDX link oder gar keinen und das auch mit
einem unmanaged switch.

Solaris hatte für jeden Interface-Typ eine .conf-Datei, dort hat man das
alles eingetragen. War hübsch, man hatte volle Kontrolle. War die Datei
abwesend oder leer war Autonegotiation mit allen Geschwindigkeiten
eingeschaltet.

Gerrit

[Marco Moock]

Post by Kay Martinen

Post by Gerrit Heitsch

Post by Marco Moock

Wenn man Autonegotiation vollständig abschaltet muss man auf 100
Halbduplex stellen weil das das ist, was ein Switch annimmt wenn
Autonegotiation fehlschlägt.

Warum zwingend 100?
Prüft der das anhand des Fast Link Pulse?

Wie sonst.

Post by Gerrit Heitsch
Ja, die Geschwindigkeit kann aus dem Linkbeat abgeleitet werden. So
funktioniert es wenn ein Hub angeschlossen wird.
10Mbit/sec möchte man sich sparen wenn es nicht unbedingt nötig
ist, daher sollte man 100HDX nehmen.

Ich meine das es den FLP auch erst mit 100BaseT gab.

Richtig. 10 MBit/s hatte den Normal Link Pulse.

http://www.ethermanage.com/
Da ist einiges zu erklärt.

Post by Kay Martinen
Es macht aber doch auch keinen Sinn wenn man Autonegotiation an
lassen könnte und das die Geschwindigkeit einstellt aber dann manuell
auf Halb oder Vollduplex stellen könnte. Das sollte eigentlich nicht
möglich sein oder?

Man kann aber steuern, was man anbieten (für jede Geschwindigkeit auch
fdx/hdx) will (wenn das Gerät so eine Option bietet). Der größte
gemeinsame Nenner wird dann genommen.

[Michael Landenberger]

Post by Michael Landenberger
Am Drucker sind 100 MBit/s Vollduplex fest eingestellt. Warum funktioniert
das in Situation 1 und 3, aber nicht in 2?

Das ist ein Fehler. Darf man nur machen wenn man den Drucker so einstellt,
daß er weiterhin Autonegotiation macht aber dann nur 100FDX als
Geschwindigkeit anbietet.

Diese Einstellung gibt es am Drucker nicht. Es gibt nur "Auto", "10BASE-T
Halbduplex", "10BASE-T Vollduplex", "100BASE-TX Halbduplex" und "100BASE-TX
Vollduplex".

Ich habe jetzt wieder "Auto" eingestellt. Beim nächsten Druckjob werde ich ja
sehen, wie schnell der Drucker druckt. Allerdings wird es ein bisschen dauern,
bis ich dazu komme, wieder den TP-Link Switch anzuschließen. Bis dahin hängt
der Drucker am Netgear-Switch, an dem er auch mit der festen Einstellung mit
der richtigen Geschwindigkeit gedruckt hat. Dazu habe ich folgende Vermutung:
im Gegensatz zum TP-Link-Switch schalten der Netgear-Switch und die Fritzbox
nicht auf Halbduplex, wenn Autonegotiation fehlschlägt, sondern auf 100 MBit/s
Vollduplex. Dann passen Drucker- und Switch-Einstellung zusammen und alles
funktioniert normal.

Woran der Drucker angeschlossen war, als ich die Geschwindigkeit fest auf 100
Vollduplex eingestellt habe (und wo das auch tatsächlich etwas gebracht hat),
weiß ich nicht mehr. Ist schon lange her. Probleme gab das auch erst, als ich
den Drucker an den TP-Link-Switch anschließen wollte. Allerdings fällt mir
ein, dass der Drucker auch schon mal per WLAN mit dem Router verbunden war,
wobei der Router im gleichen Raum und nur ca. 2m vom Drucker entfernt stand.
Auch da war er trotz perfekter Verbindung schnarchlangsam. Genau deswegen habe
ich ihn per Kabel angeschlossen.

Gruß

Michael

[Gerrit Heitsch]

Post by Michael Landenberger

Post by Michael Landenberger
Am Drucker sind 100 MBit/s Vollduplex fest eingestellt. Warum funktioniert
das in Situation 1 und 3, aber nicht in 2?

Das ist ein Fehler. Darf man nur machen wenn man den Drucker so einstellt,
daß er weiterhin Autonegotiation macht aber dann nur 100FDX als
Geschwindigkeit anbietet.

Diese Einstellung gibt es am Drucker nicht. Es gibt nur "Auto", "10BASE-T
Halbduplex", "10BASE-T Vollduplex", "100BASE-TX Halbduplex" und "100BASE-TX
Vollduplex".
Ich habe jetzt wieder "Auto" eingestellt. Beim nächsten Druckjob werde ich ja
sehen, wie schnell der Drucker druckt. Allerdings wird es ein bisschen dauern,
bis ich dazu komme, wieder den TP-Link Switch anzuschließen. Bis dahin hängt
der Drucker am Netgear-Switch, an dem er auch mit der festen Einstellung mit
im Gegensatz zum TP-Link-Switch schalten der Netgear-Switch und die Fritzbox
nicht auf Halbduplex, wenn Autonegotiation fehlschlägt, sondern auf 100 MBit/s
Vollduplex. Dann passen Drucker- und Switch-Einstellung zusammen und alles
funktioniert normal.

Ja, es sei denn man hätte dort einen Hub angeschlossen, dann würde es
kräftig scheppern. 100MBit-Hubs sind allerdings selten geworden.
Trotzdem ist das korrekte Verhalten bei fehlgeschlagener Autonegotiation
die Einstellung auf Halbduplex. Alles andere verletzt die Spec.

Post by Michael Landenberger
Auch da war er trotz perfekter Verbindung schnarchlangsam. Genau deswegen habe
ich ihn per Kabel angeschlossen.

Per Kabel ist der Anschluss der Wahl wenn man garantierte
Geschwindigkeit braucht. WLAN ist zu sehr abhängig von der Umgebung und
den dort vorhandenen anderen APs.

Gerrit

[Ralph Aichinger]

Post by Gerrit Heitsch
Ja, es sei denn man hätte dort einen Hub angeschlossen, dann würde es
kräftig scheppern. 100MBit-Hubs sind allerdings selten geworden.

Alle Hubs sind selten geworden. Ich vermute, wenn Leute in den letzten
10 Jahren Netzwerke gelernt haben, dann haben sie ein Hub nur gesehen,
wenn sie ein ausgeprägtes historisches Interesse haben, oder man ihnen
im Netzwerklabor ein zur Seite gelegtes zum Spielen gegeben hat.

/ralph

[Marco Moock]

Post by Ralph Aichinger

Post by Gerrit Heitsch
Ja, es sei denn man hätte dort einen Hub angeschlossen, dann würde
es kräftig scheppern. 100MBit-Hubs sind allerdings selten geworden.

Alle Hubs sind selten geworden. Ich vermute, wenn Leute in den letzten
10 Jahren Netzwerke gelernt haben, dann haben sie ein Hub nur gesehen,
wenn sie ein ausgeprägtes historisches Interesse haben, oder man ihnen
im Netzwerklabor ein zur Seite gelegtes zum Spielen gegeben hat.

Um Ethernet zu verstehen ist ein Blick in die Vergangenheit - da ist
der Hub ja noch relativ neu - erforderlich.
Sonst fragt man sich halt öfter mal, warum bestimmte Sachen da so sind,
wie sie sind.

[Ralph Aichinger]

Post by Marco Moock
Um Ethernet zu verstehen ist ein Blick in die Vergangenheit - da ist
der Hub ja noch relativ neu - erforderlich.
Sonst fragt man sich halt öfter mal, warum bestimmte Sachen da so sind,
wie sie sind.

Ja, ist definitiv so, aber außerhalb von Netzwerklabors und
Vintage-Computing-Aktivitäten gibt es halt keine Hubs mehr. Ich glaube
ich hab mir eines irgendwo am Dachboden zurückgelegt (damals mit der
Vorstellung "wenn ich eine Verbindung tcpdumpen will, ohne auf das
Zielsystem zu kommen", das war vor der Zeit erschwinglicher Switches mit
Mirroring).

/ralph

[Kay Martinen]

Post by Ralph Aichinger

Post by Marco Moock
Um Ethernet zu verstehen ist ein Blick in die Vergangenheit - da ist
der Hub ja noch relativ neu - erforderlich.
Sonst fragt man sich halt öfter mal, warum bestimmte Sachen da so sind,
wie sie sind.

Zum Beispiel warum es Halb-Duplex je gegeben hat und die
Kollisions-domäne sich über mehrere solcher Geräte erstrecken konnte,
warum es die 5-4-3 Regel gab u.s.w.

Ja, wenn man das nie benutzt hat könnte man sich diese Fragen stellen.

Post by Ralph Aichinger
Ja, ist definitiv so, aber außerhalb von Netzwerklabors und
Vintage-Computing-Aktivitäten gibt es halt keine Hubs mehr. Ich glaube
ich hab mir eines irgendwo am Dachboden zurückgelegt (damals mit der
Vorstellung "wenn ich eine Verbindung tcpdumpen will, ohne auf das
Zielsystem zu kommen",

Eine Ähnliche "Ausrede" hatte ich auch für meinen AT-MR-820TR als ich
mir Ersatz für den Defekten (Mit "Lebenslanger" Garantie) besorgte. Und
weil er so billig war gleich noch einen AT-MR420 dazu.

Da hatte ich allerdings schon mehr in Richtung Wireshark geschielt und
das ich mir da keinen Kopf machen müßte ob er Pakete nicht mit bekäme
weil HUB!

Post by Ralph Aichinger
das war vor der Zeit erschwinglicher Switches mit
Mirroring).

Habe ich jetzt einige die das können. Aber, ich habe/Musste es noch nie
benutzt(en). Und du?


Bye/
/Kay

[Ralph Aichinger]

Post by Kay Martinen
Habe ich jetzt einige die das können. Aber, ich habe/Musste es noch nie
benutzt(en). Und du?

Ja, wenn man bei irgendwelchen proprietären Dingen wissen will, was da
wirklich rauskommt.

/ralph

[Marc Haber]

Post by Kay Martinen

Post by Marco Moock
Um Ethernet zu verstehen ist ein Blick in die Vergangenheit - da ist
der Hub ja noch relativ neu - erforderlich.
Sonst fragt man sich halt öfter mal, warum bestimmte Sachen da so sind,
wie sie sind.

Zum Beispiel warum es Halb-Duplex je gegeben hat und die
Kollisions-domäne sich über mehrere solcher Geräte erstrecken konnte,
warum es die 5-4-3 Regel gab u.s.w.
Ja, wenn man das nie benutzt hat könnte man sich diese Fragen stellen.

Bis auf die Frage nach Halbduplex ist das für die heutige Praxis aber
auch völlig irrelevant.

Post by Kay Martinen
Habe ich jetzt einige die das können. Aber, ich habe/Musste es noch nie
benutzt(en). Und du?

Ich versuche möglichst auch bei der Arbeit ohne Mirrorport
auszukommen. Das liegt im Wesentlichen daran, dass die
Switchhersteller in diesem Bereich immer für Überraschungen sorgen.

Manche Dinge sind auch offensichtlich, nämlich dass man bei einem
Mirrorport, der "nur" dieselbe Geschwindigkeit hat wie die zu
monitorende Verbindung, nie sicher sein kann dass man wirklich alles
ausgeleitet bekommt, weil hier die Datenrate zweier Richtungen durch
_einen_ Port herausgequetscht wird, und das reicht halt nicht. Abhilfe
ist hier nur die nächstgrößere Technologie, die nicht immer vorhanden
ist.

Die Möglichkeit zur Zusammenfassung zweier Ports zu einem
Mirror-Trunk, damit man die doppelte Datenrate ausleiten kann, habe
ich noch nie in der Praxis gesehen, und im Switch einen Filter
eingeben um die auszuleitende Datenmenge zu reduzieren auch nie.

Und dann gibt es noch so nette Switches, die Dir die Pakete genau so
ausleiten wie sie in den Switch _hineingehen_, Du also nicht sagen
kannst "gib mir den Traffic von Port 23", sondern eher "gib mir den
Trafic der auf Port 23 reinkommt und den Traffic der für Port 23
reinkommt". Das macht den kleinen aber feinen Unterschied, wenn Port
23 ein Accessport ist, und man sich für Traffic interessiert, dessen
andere Seite über einen VLAN-Trunk erreichbar ist. Dann hat man
bestenfalls die eine Richtung tagged, die andere Richtung untagged im
ausgeleiteten Datenstrom und verliert, wenn man die Daten nicht
aufwendig nachbearbeiten möchte, den Großteil von Wirehsharks
automatischer Analyse¹.

Da freut man sich wenn der Traffic noch über einen dritten Switch
läuft, dann ist das Verkehr von einem VLAN-Trunk zu einem VLAN-Trunk
und in beide Richtungen getagged, aber dafür muss man sich darauf
verlassen können, dass der Traffic wirklich komplett dort vorbeikommt
und sowas hat man doch in heutigen Netzen wegen Redundanz eher
seltener. Außerdem sind viele Backbones heute schon im Gebäude
geroutet und nicht mehr geswitcht.

Aus diesen Gründen ist ein Mirrorport für mich beim Netzwerkdebugging
nur dritte Wahl. Mein Favorit ist tcpdump auf einem der Zielsysteme
(geht technisch nicht immer und macht oft genug Schnappatmung bei den
Regisseuren des Securitytheaters) oder das Einschleifen eines Taps in
die Zuleitung eines der Zielsysteme (macht Unterbrechung, braucht
örtliche Präsenz, löst Heisenberg aus).

Grüße
Marc

¹ oder kann Wireshark inzwischen VLAN-Tags ignorieren?

[Marc Haber]

Post by Marco Moock
Um Ethernet zu verstehen ist ein Blick in die Vergangenheit - da ist
der Hub ja noch relativ neu - erforderlich.
Sonst fragt man sich halt öfter mal, warum bestimmte Sachen da so sind,
wie sie sind.

Ich bin ja kein ausgebildeter Didaktiker, aber ich würde bei Ethernet
wie bei IP mit "so machen wir das heute" anfangen und am Ende dann die
Historie in einer halben Stunde überfliegen wenn noch Zeit ist.

Ja, das bedeutet auch mit IPv6 anzufangen.

Grüße
Marc

[Thomas Hochstein]

Post by Marc Haber
Ich bin ja kein ausgebildeter Didaktiker, aber ich würde bei Ethernet
wie bei IP mit "so machen wir das heute" anfangen [...]
Ja, das bedeutet auch mit IPv6 anzufangen.

Was denn nun? ;)

[Marc Haber]

Post by Ralph Aichinger

Post by Gerrit Heitsch
Ja, es sei denn man hätte dort einen Hub angeschlossen, dann würde es
kräftig scheppern. 100MBit-Hubs sind allerdings selten geworden.

Alle Hubs sind selten geworden. Ich vermute, wenn Leute in den letzten
10 Jahren Netzwerke gelernt haben, dann haben sie ein Hub nur gesehen,
wenn sie ein ausgeprägtes historisches Interesse haben, oder man ihnen
im Netzwerklabor ein zur Seite gelegtes zum Spielen gegeben hat.

Oder wenn der Lehrer das Lehrbuch von 1995 verwendet. Ich würde sagen
"Hubs im Unterricht behandeln" kommt oft zusammen mit "Classful IPv4
Addressing wird unterrichtet und der Lerninhalt abgeprüft".

Grüße
Marc

[Marco Moock]

Post by Marc Haber

Post by Ralph Aichinger

Post by Gerrit Heitsch
Ja, es sei denn man hätte dort einen Hub angeschlossen, dann würde
es kräftig scheppern. 100MBit-Hubs sind allerdings selten
geworden.

Alle Hubs sind selten geworden. Ich vermute, wenn Leute in den
letzten 10 Jahren Netzwerke gelernt haben, dann haben sie ein Hub
nur gesehen, wenn sie ein ausgeprägtes historisches Interesse haben,
oder man ihnen im Netzwerklabor ein zur Seite gelegtes zum Spielen
gegeben hat.

Oder wenn der Lehrer das Lehrbuch von 1995 verwendet. Ich würde sagen
"Hubs im Unterricht behandeln" kommt oft zusammen mit "Classful IPv4
Addressing wird unterrichtet und der Lerninhalt abgeprüft".

Es gibt auch heute noch solche Dinosaurier-Lehrer.
Schüler müssen da Netzklassen lernen.

[Marc Haber]

Post by Marco Moock

Post by Marc Haber
Oder wenn der Lehrer das Lehrbuch von 1995 verwendet. Ich würde sagen
"Hubs im Unterricht behandeln" kommt oft zusammen mit "Classful IPv4
Addressing wird unterrichtet und der Lerninhalt abgeprüft".

Es gibt auch heute noch solche Dinosaurier-Lehrer.
Schüler müssen da Netzklassen lernen.

Ich weiß. Ich habe das schon Generationen von frisch ausgebildeten
FISIs vor der Prüfung beigebracht und danach wieder ausgetrieben.

Grüße
Marc

[Ralph Aichinger]

Post by Marco Moock
Es gibt auch heute noch solche Dinosaurier-Lehrer.
Schüler müssen da Netzklassen lernen.

In den USA gibt es Lehrer die ihren Schülern beibringen, dass
Dinosaurier und Menschen zeitgleich gelebt haben, nachdem die
Bibel sagt, dass der Mensch einen Tag nach den Dinosauriern
erschaffen worden wäre oder so.

Und ja, das ist noch geringfügig schlimmer als was von Netzwerkklassen
zu schwafeln ;)

/ralph

[Michael Landenberger]

Post by Gerrit Heitsch

Post by Michael Landenberger
im Gegensatz zum TP-Link-Switch schalten der Netgear-Switch und die
Fritzbox nicht auf Halbduplex, wenn Autonegotiation fehlschlägt,
sondern auf 100 MBit/s Vollduplex. Dann passen Drucker- und Switch-
Einstellung zusammen und alles funktioniert normal.

Ja, es sei denn man hätte dort einen Hub angeschlossen, dann würde es
kräftig scheppern. 100MBit-Hubs sind allerdings selten geworden.

Hubs sind hier nicht nur selten geworden, hier sind sie ausgestorben ;-)

Der letzte Hub, den ich besaß, ist vor gefühlt 30 Jahren zum Elektroschrott
gewandert.

Gruß

Michael

[Marc Haber]

Post by Michael Landenberger
im Gegensatz zum TP-Link-Switch schalten der Netgear-Switch und die Fritzbox
nicht auf Halbduplex, wenn Autonegotiation fehlschlägt, sondern auf 100 MBit/s
Vollduplex. Dann passen Drucker- und Switch-Einstellung zusammen und alles
funktioniert normal.

AVM würde ich glatt zutrauen, sich hier standardwidrig zu verhalten,
weil der Standard an dieser Stelle arg konservativ ist und man
vermutlich mit "wenn die andere Seite kein Autonegotiation macht,
nehme ich an dass sie dort absichtlich ausgeschaltet wurde und die
Gegenseite dennoch vollduplexfähig ist". Das fällt dann halt in dem
Fall auf die Nase, in der die Gegenseite fest auf Halbduplex
eingestellt ist, dann gibt es die falsch erkannten Collisions halt auf
der anderen Seite.

Du könntest im Fall "tut langsam" auch einfach mal probieren, den
Drucker auf 100 half einzustellen.

Aber Flickwerk bleibt das alles.

Grüße
Marc

[Thomas Einzel]

Post by Marc Haber

Post by Michael Landenberger
im Gegensatz zum TP-Link-Switch schalten der Netgear-Switch und die Fritzbox
nicht auf Halbduplex, wenn Autonegotiation fehlschlägt, sondern auf 100 MBit/s
Vollduplex. Dann passen Drucker- und Switch-Einstellung zusammen und alles
funktioniert normal.

AVM würde ich glatt zutrauen, sich hier standardwidrig zu verhalten,
weil der Standard an dieser Stelle arg konservativ ist und man
vermutlich mit "wenn die andere Seite kein Autonegotiation macht,
nehme ich an dass sie dort absichtlich ausgeschaltet wurde und die
Gegenseite dennoch vollduplexfähig ist". Das fällt dann halt in dem
Fall auf die Nase, in der die Gegenseite fest auf Halbduplex
eingestellt ist, dann gibt es die falsch erkannten Collisions halt auf
der anderen Seite.

...
Ich hatte letztes Jahr ein kleines Problem, mit einer
fehlenden/wackelndes Ader (ausgerechnet in meiner längsten
Netzwerkleitung und auch noch mit mit 2 LSA Verbindern) und einen
erfolglosen Versuch daran einen Trendnet TPE-P521ES (PoE PD) an einem
TP-Link TL-SG2428 via PoE und FastEthernet zu betreiben.
PoE Endspan Mode A (Adern 1/2 und 3/6). (mit einem PoE Tester, der neben
den Adern u.a. auch Spannungen misst, geprüft)

PoE hat funktioniert, der Trendnet PD Switch war an, aber es ist keine
Netzwerkverbindung zustande gekommen. Lokal an dem PD Switch haben die
Ports untereinander funktioniert. Nach mehreren manuellen setzen an den
Ports der beiden Switche ging dann tatsächlich FastEthernet Fullduplex.
Aber mit Autonegotiation ging in diesem Fall gar nichts.

Mit anderen Switchkonstellationen hatte ich in solchen "Spezialfällen"
bisher immer FastEthernet mit Autonegotiation.

Post by Marc Haber
Aber Flickwerk bleibt das alles.

Ja ;-), nach flicken der Leitung ging es wieder mit 1GBit via
Autonegotiation.

Vorsorglich: die Auswahl an kleinen PoE PD switches (Spannung nur via
PD) mit PoE Pass Through (mind. 15W auf 2 Ports), die mindestens soweit
konfigurierbar sind, dass VLAN einstellbar sind ist extrem
übersichtlich. Netgear und Trendnet habe ich, AFAIK gibt es noch einen
von Ubiquiti.

[Marc Haber]

Post by Thomas Einzel
Vorsorglich: die Auswahl an kleinen PoE PD switches (Spannung nur via
PD) mit PoE Pass Through (mind. 15W auf 2 Ports), die mindestens soweit
konfigurierbar sind, dass VLAN einstellbar sind ist extrem
übersichtlich. Netgear und Trendnet habe ich, AFAIK gibt es noch einen
von Ubiquiti.

Es gab mal einen hübschen kleinen Procurve, leider hab ich versäumt
mir mindestens einen in den Schrank zu legen.

Grüße
Marc

[Michael Landenberger]

Post by Marc Haber
Du könntest im Fall "tut langsam" auch einfach mal probieren, den
Drucker auf 100 half einzustellen.
Aber Flickwerk bleibt das alles.

Der Drucker steht jetzt wieder auf "Auto". Ich nehme an, das ist kein
Flickwerk.

Gruß

Michael

[Marc Haber]

Post by Michael Landenberger

Post by Marc Haber
Du könntest im Fall "tut langsam" auch einfach mal probieren, den
Drucker auf 100 half einzustellen.
Aber Flickwerk bleibt das alles.

Der Drucker steht jetzt wieder auf "Auto". Ich nehme an, das ist kein
Flickwerk.

Bis auf den nicht managebaren switch nicht, nein.

Grüße
Marc

[Michael Landenberger]

Post by Marc Haber

Post by Michael Landenberger
Der Drucker steht jetzt wieder auf "Auto". Ich nehme an, das ist kein
Flickwerk.

Bis auf den nicht managebaren switch nicht, nein.

Warum sollte man in einem Heimnetzwerk einen managebaren Switch einsetzen? Was
für Vorteile bringt der da?

Gruß

Michael

[Marco Moock]

Post by Michael Landenberger
Warum sollte man in einem Heimnetzwerk einen managebaren Switch
einsetzen? Was für Vorteile bringt der da?

Dass man da Logging und Einstellmöglichkeiten (z.B. zu Autonegotiation)
hat.

[Gerrit Heitsch]

Post by Marco Moock

Post by Michael Landenberger
Warum sollte man in einem Heimnetzwerk einen managebaren Switch
einsetzen? Was für Vorteile bringt der da?

Dass man da Logging und Einstellmöglichkeiten (z.B. zu Autonegotiation)
hat.

Hardware die Probleme mit Autonegotiation hat sollte es nur noch ähnlich
oft wie Ethernet-Hubs geben. Selbst Cisco bekommt das inzwischen hin.

Gerrit

[Marco Moock]

Post by Gerrit Heitsch

Post by Marco Moock

Post by Michael Landenberger
Warum sollte man in einem Heimnetzwerk einen managebaren Switch
einsetzen? Was für Vorteile bringt der da?

Dass man da Logging und Einstellmöglichkeiten (z.B. zu
Autonegotiation) hat.

Hardware die Probleme mit Autonegotiation hat sollte es nur noch
ähnlich oft wie Ethernet-Hubs geben.

Sollte...

Post by Gerrit Heitsch
Selbst Cisco bekommt das inzwischen hin.

Gab es damit früher Probleme?
Die 2950er, die ich habe, machten da keine. Oder war das noch früher?

[Marc Haber]

Post by Marco Moock

Post by Gerrit Heitsch
Selbst Cisco bekommt das inzwischen hin.

Gab es damit früher Probleme?

Vor 25 Jahren hatten wir mit sowas viel Spaß. Aus dieser Zeit stammen
die Geschichten, dass man bei Problemen mit Ethernet Duplex und Speed
festlegen soll. Was das wirklich bedeutet, habe ich auch erst 15 Jahre
später gelernt.

Grüße
Marc

[Gerrit Heitsch]

Post by Marco Moock

Post by Gerrit Heitsch

Post by Marco Moock

Post by Michael Landenberger
Warum sollte man in einem Heimnetzwerk einen managebaren Switch
einsetzen? Was für Vorteile bringt der da?

Dass man da Logging und Einstellmöglichkeiten (z.B. zu
Autonegotiation) hat.

Hardware die Probleme mit Autonegotiation hat sollte es nur noch
ähnlich oft wie Ethernet-Hubs geben.

Sollte...

Mir ist schon SEHR lange nichts mehr in der Richtung untergekommen.

Post by Marco Moock

Post by Gerrit Heitsch
Selbst Cisco bekommt das inzwischen hin.

Gab es damit früher Probleme?
Die 2950er, die ich habe, machten da keine. Oder war das noch früher?

Keine Ahnung wie die hiessen, aber so 2000 rum wurde immer empfohlen bei
Cisco 100FDX fest einzustellen.

Gerrit

[Marco Moock]

Post by Gerrit Heitsch

Post by Marco Moock

Post by Gerrit Heitsch

Post by Marco Moock

Post by Michael Landenberger
Warum sollte man in einem Heimnetzwerk einen managebaren Switch
einsetzen? Was für Vorteile bringt der da?

Dass man da Logging und Einstellmöglichkeiten (z.B. zu
Autonegotiation) hat.

Hardware die Probleme mit Autonegotiation hat sollte es nur noch
ähnlich oft wie Ethernet-Hubs geben.

Sollte...

Mir ist schon SEHR lange nichts mehr in der Richtung untergekommen.

Post by Marco Moock

Post by Gerrit Heitsch
Selbst Cisco bekommt das inzwischen hin.

Gab es damit früher Probleme?
Die 2950er, die ich habe, machten da keine. Oder war das noch früher?

Keine Ahnung wie die hiessen, aber so 2000 rum wurde immer empfohlen
bei Cisco 100FDX fest einzustellen.

Dann waren das Vorgängermodelle.
Ob es schon der 2900XL war?

[Kay Martinen]

Post by Marco Moock

Post by Marco Moock

Post by Gerrit Heitsch

Post by Marco Moock

Post by Michael Landenberger
Warum sollte man in einem Heimnetzwerk einen managebaren Switch
einsetzen? Was für Vorteile bringt der da?

Dass man da Logging und Einstellmöglichkeiten (z.B. zu
Autonegotiation) hat.

Hardware die Probleme mit Autonegotiation hat sollte es nur noch
ähnlich oft wie Ethernet-Hubs geben.

Mir ist schon SEHR lange nichts mehr in der Richtung untergekommen >>>

Post by Marco Moock

Post by Gerrit Heitsch
Selbst Cisco bekommt das inzwischen hin.

Gab es damit früher Probleme?
Die 2950er, die ich habe, machten da keine. Oder war das noch früher?

Keine Ahnung wie die hiessen, aber so 2000 rum wurde immer empfohlen
bei Cisco 100FDX fest einzustellen.

Hatten die denn alle schon autonegotiation? Oder etwas cisco-eigenes
N-Way-tralala Gedöns. Mit ISL haben die ja auch etwas eigenes gebacken.

Post by Marco Moock
Dann waren das Vorgängermodelle.
Ob es schon der 2900XL war?

Möglicherweise, obwohl ich mich daran nicht mehr erinnere ob ich
Probleme hatte. Ich hab hier 2924XL und 2924M-XL noch liegen. AFAIR
waren die sehr ähnlich zu den 3500XL von denen ich auch noch 2 habe.

Die Modellnummern bei Cisco sind ja nun auch nicht unbedingt
Chronologisch aufsteigend, manche gab es parallel und höhere Nummer =
Neuer trifft gewöhnlich eher nicht zu.

Bye/
/Kay

[Marc Haber]

Post by Michael Landenberger

Post by Marc Haber

Post by Michael Landenberger
Der Drucker steht jetzt wieder auf "Auto". Ich nehme an, das ist kein
Flickwerk.

Bis auf den nicht managebaren switch nicht, nein.

Warum sollte man in einem Heimnetzwerk einen managebaren Switch einsetzen? Was
für Vorteile bringt der da?

Man ist halt nicht auf irgendwelche unzuverlässigen Automatismen
angewiesen. Siehe das vorliegende Problem, das sich durch einen Blick
auf die auslesbaren¹ Fehlerzähler direkt offenbart hätte.

Grüße
Marc

¹ Fehlerzähler hat das Silizium in Deien Switchen sicher auch, Du
kommst halt nur nicht ran

[Michael Landenberger]

Post by Marc Haber

Post by Michael Landenberger
Warum sollte man in einem Heimnetzwerk einen managebaren Switch einsetzen?
Was für Vorteile bringt der da?

Man ist halt nicht auf irgendwelche unzuverlässigen Automatismen
angewiesen. Siehe das vorliegende Problem, das sich durch einen Blick
auf die auslesbaren¹ Fehlerzähler direkt offenbart hätte.

Das ist in 30 Jahren das erste Mal, dass bei mir im Heimnetzwerk (!) so ein
Fehler aufgetreten ist. Ansonsten hätte ich von einem managebaren Switch in
den ganzen Jahren nicht im Geringsten profitiert. Switches laufen bei mir
unter "anschließen - funzt". Weil sie nämlich genau das über Jahrzehnte getan
haben.

Im professionellen Umfeld sieht das natürlich anders aus. Da sehe ich den Sinn
von managebaren Switches durchaus.

Gruß

Michael

[Marc Haber]

Post by Michael Landenberger

Post by Marc Haber

Post by Michael Landenberger
Warum sollte man in einem Heimnetzwerk einen managebaren Switch einsetzen?
Was für Vorteile bringt der da?

Man ist halt nicht auf irgendwelche unzuverlässigen Automatismen
angewiesen. Siehe das vorliegende Problem, das sich durch einen Blick
auf die auslesbaren¹ Fehlerzähler direkt offenbart hätte.

Das ist in 30 Jahren das erste Mal, dass bei mir im Heimnetzwerk (!) so ein
Fehler aufgetreten ist. Ansonsten hätte ich von einem managebaren Switch in
den ganzen Jahren nicht im Geringsten profitiert. Switches laufen bei mir
unter "anschließen - funzt". Weil sie nämlich genau das über Jahrzehnte getan
haben.

Dann lass es halt so.

[Kay Martinen]

Post by Marc Haber

Post by Michael Landenberger

Post by Marc Haber
Bis auf den nicht managebaren switch nicht, nein.

Warum sollte man in einem Heimnetzwerk einen managebaren Switch einsetzen? Was
für Vorteile bringt der da?

Man ist halt nicht auf irgendwelche unzuverlässigen Automatismen
angewiesen. Siehe das vorliegende Problem, das sich durch einen Blick
auf die auslesbaren¹ Fehlerzähler direkt offenbart hätte.
¹ Fehlerzähler hat das Silizium in Deien Switchen sicher auch, Du
kommst halt nur nicht ran

Darum meine Frage ob das ein TL-SG105E ist. Bei DEM kommt man an die
Zähler. Und auch an die Port-Konfig, Multicast-Liste (wenn IGMP-Snoop
aktiv ist) u.s.w.. Man kann dummerweise nur keinen Port vom Default-VLAN
befreien, das ist IMMER mit dabei. Aber da dieses eh nur "untagged" ist...

Bye/
/Kay

[Thomas Einzel]

Post by Michael Landenberger

Post by Marc Haber

Post by Michael Landenberger
Der Drucker steht jetzt wieder auf "Auto". Ich nehme an, das ist kein
Flickwerk.

Bis auf den nicht managebaren switch nicht, nein.

Warum sollte man in einem Heimnetzwerk einen managebaren Switch einsetzen? Was
für Vorteile bringt der da?

z.B. wenn man mehr VLANs möchte als für ein Gastnetz, oder Einstellungen
wie im Thread auf eine bestimmte "Portgeschwindigkeit", oder
halb-/vollduplex, (wie im Thread). Traffic Shaping je Port, falls man
das benötigt, wäre auch noch ein Grund, oder in gewissen Grenzen auch
QoS. Obwohl es nicht konfigurierbare Switches mit PoE gibt, würde ich
bei PoE immer einen konfigurierbaren Switch empfehlen.

Wer das alles nicht möchte, kann wahrscheinlich auf konfigurierbare
Switches verzichten.

[Ralph Aichinger]

Post by Thomas Einzel
z.B. wenn man mehr VLANs möchte als für ein Gastnetz, oder Einstellungen
wie im Thread auf eine bestimmte "Portgeschwindigkeit", oder
halb-/vollduplex, (wie im Thread). Traffic Shaping je Port, falls man
das benötigt, wäre auch noch ein Grund, oder in gewissen Grenzen auch
QoS. Obwohl es nicht konfigurierbare Switches mit PoE gibt, würde ich
bei PoE immer einen konfigurierbaren Switch empfehlen.

Je nachdem halt kann auch Port Mirroring bei der Fehlersuche hilfreich
sein.

/ralph

[Thomas Einzel]

Post by Ralph Aichinger

Post by Thomas Einzel
z.B. wenn man mehr VLANs möchte als für ein Gastnetz, oder Einstellungen
wie im Thread auf eine bestimmte "Portgeschwindigkeit", oder
halb-/vollduplex, (wie im Thread). Traffic Shaping je Port, falls man
das benötigt, wäre auch noch ein Grund, oder in gewissen Grenzen auch
QoS. Obwohl es nicht konfigurierbare Switches mit PoE gibt, würde ich
bei PoE immer einen konfigurierbaren Switch empfehlen.

Je nachdem halt kann auch Port Mirroring bei der Fehlersuche hilfreich
sein.

Habe ich im privaten Umfeld noch nicht benutzt, du?

[Ralph Aichinger]

Post by Thomas Einzel

Post by Ralph Aichinger
Je nachdem halt kann auch Port Mirroring bei der Fehlersuche hilfreich
sein.

Habe ich im privaten Umfeld noch nicht benutzt, du?

Ja, wenn man z.B. nicht weiß ob aus einem Gerät wirklich ein Paket
rein/rauskommt, man aber keine Möglichkeit hat sich aufs betroffene Gerät
einzuloggen und tcpdump oder was in der Art zu starten.

/ralph

[Kay Martinen]

Post by Ralph Aichinger

Post by Thomas Einzel

Post by Ralph Aichinger
Je nachdem halt kann auch Port Mirroring bei der Fehlersuche hilfreich
sein.

Habe ich im privaten Umfeld noch nicht benutzt, du?

Hier: Auch nicht.

Post by Ralph Aichinger
Ja, wenn man z.B. nicht weiß ob aus einem Gerät wirklich ein Paket
rein/rauskommt, man aber keine Möglichkeit hat sich aufs betroffene Gerät
einzuloggen und tcpdump oder was in der Art zu starten.

Im "Privaten" Umfeld? Da dürfte normalerweise KEIN Gerät 100m Entfernt
sein und man selbst nicht Admin(wider willen) ist.

Und Marc's Antwort nebenan erinnerte mich auch dran das es eben nicht so
trivial sein kann. Früher hab ich nur theoretisch überlegt das der
mirrorport idealerweise schneller ist als der von dem die Daten
gespiegelt werden sollen.

Bye/
/Kay

[Ralph Aichinger]

Post by Kay Martinen
Im "Privaten" Umfeld? Da dürfte normalerweise KEIN Gerät 100m Entfernt
sein und man selbst nicht Admin(wider willen) ist.

Ob das Gerät 100m entfernt ist oder auf meinem Schreibtisch ist, wenn
ich Fehler suche, dann hilft mir dabei z.B. Portmirroring. Weil zu
wissen, was tatsächlich übers Kabel geht oft sehr hilfreich ist.

Soll heißen: Hat nicht unbedingt was mit der Entfernung zu tun.

/ralph

[Kay Martinen]

Post by Ralph Aichinger

Post by Kay Martinen
Im "Privaten" Umfeld? Da dürfte normalerweise KEIN Gerät 100m Entfernt
sein und man selbst nicht Admin(wider willen) ist.

Ob das Gerät 100m entfernt ist oder auf meinem Schreibtisch ist, wenn
ich Fehler suche, dann hilft mir dabei z.B. Portmirroring. Weil zu
wissen, was tatsächlich übers Kabel geht oft sehr hilfreich ist.
Soll heißen: Hat nicht unbedingt was mit der Entfernung zu tun.

Schon richtig, auch Marc's Einwand (Settop Box o.a.) aber ich nahm an es
wäre im Firmen-umfeld wichtiger und sinnvoller.

Zu Hause ist man entweder admin auf dem Gerät oder könnte solche
Speziellen Kisten ggf. auch mal über einen Hub mit dem Notebook zusammen
an klemmen. Dann sieht man auch jedes Bit.

Oder, ähh, hattest DU gesagt das du deinen Letzten Hub verschrottet
hattest? :)

Wenn ich bei meinem (SAT-Receiver ohne WoL) Beispiel bliebe: Das Tool
starten um einen der nur 5 Switchports auf mirror zu schalten und dann
noch einen Laptop hin tragen und anschließen... ich glaub da ist's
einfacher den ersten Schritt aus zu lassen, den Hub dazwischen zu
stecken und direkt zu lauschen.


Bye/
/Kay

[Ralph Aichinger]

Post by Kay Martinen
Zu Hause ist man entweder admin auf dem Gerät oder könnte solche
Speziellen Kisten ggf. auch mal über einen Hub mit dem Notebook zusammen
an klemmen. Dann sieht man auch jedes Bit.

Ja, genau, der managed Switch ist der Ersatz für den historischen Hub ;)

Praktisch kann auch die Überwachung einzelner Ports für irgendwelche
Automatisierungen sein, oder das aus/einschalten von Geräten per PoE
oder solche Dinge.

/ralph -- nein, Mainstreamprogramm ist das alles nix, aber in
Einzelfällen ganz praktisch

[Kay Martinen]

Post by Ralph Aichinger

Post by Kay Martinen
Zu Hause ist man entweder admin auf dem Gerät oder könnte solche
Speziellen Kisten ggf. auch mal über einen Hub mit dem Notebook zusammen
an klemmen. Dann sieht man auch jedes Bit.

Ja, genau, der managed Switch ist der Ersatz für den historischen Hub ;)

Und umgekehrt - wenn man noch einen hat. ;)

Post by Ralph Aichinger
Praktisch kann auch die Überwachung einzelner Ports für irgendwelche
Automatisierungen sein, oder das aus/einschalten von Geräten per PoE
oder solche Dinge.

Du meinst, dauerhaftes Mirroring um aus empfangenen Paketen
schaltbefehle ab zu leiten?

Dazu muß der Port am Zielhost des mirroring doch im Promiscuos mode
bleiben. Und wie fängst du dort dann die passenden Datenpakete ein? Mit
einem tcpdump in dauerschleife, irgendwas mit 'netcat' oder ???

Post by Ralph Aichinger
/ralph -- nein, Mainstreamprogramm ist das alles nix, aber in
Einzelfällen ganz praktisch

Ja, an diese Möglichkeit habe ich auch noch nicht gedacht. Eher an eine
(per IP, USB, ???) Schaltbare Steckdosenleiste. Ich hab so eine deren
Windows-Tool z.b. dem Drucker den strom an werfen könnte wenn der
Spooler daten bekommt. Oder eine Externe Platte an wirft wenn drauf
zugegriffen werden soll. Das war noch XP so weit ich erinnere und das
tool quitschbunt wie damals üblich.

Das sispmctl für linux kann das nicht, aber es bringt einen Webserver
mit über den man das manuell per Web-Click an werfen kann. Hatte ich
eine Zeitlang an einem raspi um im Keller Aktionen (fern) aus zu lösen.
Aber sispmctl ist ein shell tool das parameter kennt. Also z.b. auch aus
einem Script, crontab o.a. zu starten.

Nur falls du ne Alternative suchtest...

Bye/
/Kay

[Ralph Aichinger]

Post by Kay Martinen
Du meinst, dauerhaftes Mirroring um aus empfangenen Paketen
schaltbefehle ab zu leiten?

Nein, neben dem Mirroring kann man auch mit Portüberwachung (z.B. Link
an Port X-> Y machen) oder per PoE lustige Dinge machen.

Z.B. kannst du Home Assistant ein Licht einschalten lassen, wenn jemand
irgendwas in einen bestimmten Netzwerkport steckt, oder solche Dinge,
oder das Licht nach der Downloadgeschwindigkeit einfärben oder so.

/ralph

[Kay Martinen]

Post by Ralph Aichinger

Post by Kay Martinen
Du meinst, dauerhaftes Mirroring um aus empfangenen Paketen
schaltbefehle ab zu leiten?

Nein, neben dem Mirroring kann man auch mit Portüberwachung (z.B. Link
an Port X-> Y machen) oder per PoE lustige Dinge machen.

Hmm, linkstatus via snmp abfragen? Dann hab ich dich wohl falsch
verstanden das es mittels mirroring ginge. Das der mirrorport dem
linkstatus seines quellports folgt hätte ich nicht erwartet?

Vor jahren las ich mal eine Anleitung wie man mittels µC den Linktraffic
via snmp ausließt und dann ein Analoginstrument ansteuert. ;)

Post by Ralph Aichinger
Z.B. kannst du Home Assistant ein Licht einschalten lassen, wenn jemand
irgendwas in einen bestimmten Netzwerkport steckt, oder solche Dinge,
oder das Licht nach der Downloadgeschwindigkeit einfärben oder so.

Naja, mit SchmartHome Kram kann man einiges machen. Letzteres würde ich
hier aber nicht versuchen. Das hätte einen Dunkelbirnen-Effekt (Beim
Einschalten wird es dunkler) ;)

Bye/
/Kay

[Marc Haber]

Post by Kay Martinen

Post by Ralph Aichinger
Ja, wenn man z.B. nicht weiß ob aus einem Gerät wirklich ein Paket
rein/rauskommt, man aber keine Möglichkeit hat sich aufs betroffene Gerät
einzuloggen und tcpdump oder was in der Art zu starten.

Im "Privaten" Umfeld? Da dürfte normalerweise KEIN Gerät 100m Entfernt
sein und man selbst nicht Admin(wider willen) ist.

Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und eine
Settopbox?

Grüße
Marc

[Kay Martinen]

Post by Marc Haber

Post by Kay Martinen

Post by Ralph Aichinger
Ja, wenn man z.B. nicht weiß ob aus einem Gerät wirklich ein Paket
rein/rauskommt, man aber keine Möglichkeit hat sich aufs betroffene Gerät
einzuloggen und tcpdump oder was in der Art zu starten.

Im "Privaten" Umfeld? Da dürfte normalerweise KEIN Gerät 100m Entfernt
sein und man selbst nicht Admin(wider willen) ist.

Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und eine
Settopbox?

Oder mein SAT-Receiver hier. Hat LAN, könnte WLAN aber "Wake" on LAN
kennt er nicht. Aktuell keine 3 Meter entfernt von mir, aber an einem
dummen switch hängend der wiederum an einem SmartSwitch hängt. Der
Mirroring könnte. Aber WoL bekäme ich auch damit nicht zum laufen - wenn
man mal annimmt das der Receiver es tatsächlich nicht kann. Ok, ich
"könnte" das durch Mirroring verifizieren ob das Magic Packet bis dahin
käme. Bei den o.g. 3 Metern spare ich mir das. ;)

Ja, solche Blackboxes hatte ich nicht auf der Liste. Ich wollte mit
obigem eher auf PCs u.ä. administrierbare Geräte zielen. Die man ja auch
in einem Firmennetz hätte - wo sie deutlich weiter auseinander liegen
könnten und man evtl. nicht mal admin-recht drauf hätte.

Von den genannten Ausnahmen hat man im Privaten LAN aber eher immer die
Zugangsmöglichkeit. Und bevor der Einwand kommt: Möglichkeit! Nicht
unbedingt auch die Befähigung. :) Preis der ONU-Tauglichkeit.

Bye/
/Kay

[Marco Moock]

Post by Marc Haber
Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und eine
Settopbox?

Solche Geräte meide ich wo es nur geht.

[Marc Haber]

Post by Marco Moock

Post by Marc Haber
Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und eine
Settopbox?

Solche Geräte meide ich wo es nur geht.

Geht halt nicht immer.

Grüße
Marc

[Gerald E¡scher]

Post by Marco Moock

Post by Marc Haber
Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und eine
Settopbox?

Solche Geräte meide ich wo es nur geht.

Verwendest du keinen Drucker?

[Marco Moock]

Post by Gerald E¡scher

Post by Marco Moock

Post by Marc Haber
Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und
eine Settopbox?

Solche Geräte meide ich wo es nur geht.

Verwendest du keinen Drucker?

Doch, aber mit LPT oder USB.
Per Netzwerk könnte ich den per lpr erreichbar machen, habe ich aber
nicht, da ich so selten drucke, dass ich da den Laptop mit in den
Keller nehme und gut.

[Kay Martinen]

Post by Marco Moock

Post by Gerald E¡scher

Post by Marco Moock

Post by Marc Haber
Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und
eine Settopbox?

Solche Geräte meide ich wo es nur geht.

Verwendest du keinen Drucker?

Doch, aber mit LPT oder USB.
Per Netzwerk könnte ich den per lpr erreichbar machen, habe ich aber
nicht,

Den Drucker selbst direkt per LAN mit lpr - oder doch nur über eine
lpr-freigabe auf dem host an dem er hängt?

Post by Marco Moock
da ich so selten drucke, dass ich da den Laptop mit in den
Keller nehme und gut.

Ich bin mir FAST sicher er meinte damit ob die Firmware in deinem
Drucker dir die Möglichkeit bietet eine shell auszuführen in der du ein
tcpdump starten könntest.... Wie es oben auch schon steht.

Ich drucke auch nur noch selten aber dazu gehe ich nicht mit dem Laptop
in den Keller. Dort habe ich Server - aber keinen Drucker. ;-)

Bye/
/Kay

[Gerald E¡scher]

Post by Marco Moock

Post by Gerald E¡scher

Post by Marco Moock

Post by Marc Haber
Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS und
eine Settopbox?

Solche Geräte meide ich wo es nur geht.

Verwendest du keinen Drucker?

Doch, aber mit LPT oder USB.

LPT ist voriges Jahrtausend und USB vorvoriges Jahrzehnt. Für dich muss
sich das etwa so anfühlen, als würde ich einen seriell angeschlossenen
Kettendrucker benutzen ;-)

Post by Marco Moock
Per Netzwerk könnte ich den per lpr erreichbar machen,

Kein CUPS vorhanden? Mit CUPS lässt sich ein Drucker watscheneinfach im
Netzwerk freigeben.
Ist der Drucker so alt, dass er keinen Netzwerkanschluss hat? Wie auch
immer, tcpdump kann man bei Druckern eher nicht verwenden.

[Marco Moock]

Post by Gerald E¡scher

Post by Marco Moock

Post by Gerald E¡scher

Post by Marco Moock

Post by Marc Haber
Aber wenn beide Geräte nicht tcpdump-fähig sind, z.B. ein NAS
und eine Settopbox?

Solche Geräte meide ich wo es nur geht.

Verwendest du keinen Drucker?

Doch, aber mit LPT oder USB.

LPT ist voriges Jahrtausend und USB vorvoriges Jahrzehnt.

Noch heute gibt es Drucker nur mit USB. Ist an jedem normalen Rechner
vorhanden und erfüllt die Funktion.

Post by Gerald E¡scher

Post by Marco Moock
Per Netzwerk könnte ich den per lpr erreichbar machen,

Kein CUPS vorhanden? Mit CUPS lässt sich ein Drucker watscheneinfach
im Netzwerk freigeben.

Doch, war sogar der lpr-Dienst vom CUPS, als ich das damals
eingerichtet hatte. Grund war, dass mein Rechner kein LPT hatte und ich
dann einen anderen Rechner als Druckserver eingerichtet hatte. Jetzt
nicht mehr nötig, da mein neuer Rechner wieder LPT hat.

Das Tolle daran: Man hat Kontrolle über das Zeug.

Post by Gerald E¡scher
Ist der Drucker so alt, dass er keinen Netzwerkanschluss hat?

Der eine ja (OfficeJet 350), der andere ist von 2014 und hat nur USB.
Die Netzwerk-Variante gibt es auch, aber dieses Modell hat das halt
nicht. Wurde deswegen aussortiert und ich bekam den kostenlos. Musste
zwar erstmal auslüften und beim Drucken merkt man noch immer, dass der
mal in ner Raucherwohnung stand, aber egal. Hat zwar wegen des Samsung
uld auch schon Ärger gemacht, tut aber aktuell.