PC verliert unregelmäßig nach einigen Tagen Netzwerkverbindung

cobas

Newbie
Registriert
Jan. 2017
Beiträge
3
Hallo,
vorab: ich weiß, dass die nachfolgend erwähnte Netzwerkkonfiguration keinesfalls üblich ist, aber es gibt etwas, was ich mir überhaupt nicht erklären kann. Also: wir leben in einem Haus mit 3 Etagen.
1. Etage: Fritzbox 7390. Da geht die DSL Leitung von außen ein und diese dient auch als DHCP Server. Direkt daneben ein HP ProCurve 1810G. Davon gehen ein paar Kabel für die Versorgung der 1. Etage ab. Dazu ein Kabel zu einer Wanddose, die dann in der Wand in die 2. Etage führt.
2. Etage: Von der Dose (ich nenne sie mal Dose2ETG_an, da es später wichtig wird), die in die 1. Etage führt geht ein kurzes Kabel an ein TP Link TL-SG 108. Von dort wird in die 2. Etage verteilt und ein Kabel geht in eine Wanddose (ich nenne sie mal Dose2ETG_ab), die in die 3. Etage führt.
3. Etage: Von der Dose die aus der 2. Etage kommt, geht ein Kabel in ein PC

An der Konstellation was in welchen Etagen steht, möchte ich aus verschiedenen Gründen ungern etwas ändern.

Soweit läuft alles zur Zufriedenheit und stabil. Bis auf eine Sache:
Am PC (Windows 10) in der 3. Etage kommt es sporadisch mal nach 2 Tagen, mal nach 2 Wochen (bei sehr ähnlichen Nutzungsverhalten) zu einem Netzwerkfehler (Kabel angeblich nicht angeschlossen). Dann switcht die Anzeige zu "Netzwerkidentifikation" und wieder zurück zu Kabel nicht angeschlossen. Die entsprechende grüne LED am TP-Link Switch in der 2. Etage blinkt dann in dem Moment mal. Natürlich habe ich schon sehr(!) viel probiert: Kabeltausch, andere Switch als der TP Link (Netgear), etc.
Was nun hilft ist: Ein Kabel von Dose2ETG_an direkt zu Dose2ETG_ab zu verbinden. Dann erhält der PC wieder seine IP (DHCP Server ist die Fritz Box) und dann kann ich den TP Link wieder richtig anschließen. Das hält dann wieder eine Weile.
Anstatt des PCs war vorher ein Multimedialautsprecher dran, der das selbe Phänomen hatte. Ich dachte erst, es liegt am Gerät, ist aber Geräteunabhängig.
Am PC die Netzwerkeigenschaften (100 MBit Vollduplex, kein Standby,...) zu ändern, hat auch nichts verändert.
Auch eine feste IP zu vergeben, ändert nichts !

Auch wenn dieses Konstrukt sicher nicht ideal ist, wundert mich das Verhalten des PCs (oder Multimedialautsprecher) doch sehr. Warum genügt es kurz den Switch zu überbrücken und das reicht schon ?!?
Leider kann man auch so schlecht testen, denn gerade läuft ja alles bestens (vielleicht sogar für die nächsten Wochen).

Wenn jemand Ideen dazu hat, gerne her damit. Evtl. noch monitoren am PC ? Wenn ja, was genau ?

merci
Gruß
Kai
 
Kann man das IGMP-Snooping auf dem TP Link deaktivieren? Vielleicht funkt das ja dazwischen. Auch wenn du schon andere Switche probiert hast. Bekommt der PC denn einfach nur keine IP? Also was zeigt er an, wenn du dann in die cmd ipconfig /all eingibst? Kannst du schauen, ob das Phänomen vlt auftritt, wenn das DHCP Lease in der Fritzbox abgelaufen ist?

Wobei IGMP Snooping Multicasts steuert und DHCP über Broadcast laufen, n Versuch ists aber wert
Was für eine Netzwerkkarte hast du denn in dem PC drin? Aktuellste Treiber? Du hast aber keine VLANs im Einsatz, die vom Treiber aufgelöst werden oder? Wenn ja, probier das mal anders.. Setze die entsprechenden Client Ports auf den Switchen auf Untagged, dann aber nur ein VLAN auf den Port legen

Edit:

ggf ist in den Dosen was falsch aufgelegt? Sodass der sich in dem TP Link verschluckt und seine Packete im Loop durch dein LAN schießt?
 
Zuletzt bearbeitet:
Hallo Gbene,
der TP Link unterstützt zwar IGMP Snooping, aber deaktivieren kann man es meines Wissens nicht. Der PC bekommt lt. ipconfig eine IP aus einem total komischen Adressbereich (wahrscheinlich APIPA ?!). Das war bei dem Multimediaplayer auch schon. Es gibt aber auch keinen anderen DHCP Server im Netz.Ich muss das nochmal genau dokumentieren wenn der Fall wieder eintritt. An Netzwerkkarte/Treiber (aktuelle HW/SW) kann es meines Erachtens nicht liegen, da der Multimediaplayer (also ein anderes Device) genau die gleichen Probleme hatte.
VLAN ist nicht eingerichtet.
Das mit der Dose könnte eine Möglichkeit sein. Ich prüfe das mal, obwohl es für mich nicht logisch klingt (muss es aber auch nicht ;-) )

Edit:
Gibt es eine Möglichkeit, den eventuellen Zustand des Loops am PC per Software zu erkennen ? Müsste ja eigentlich durch Packetauslesen funktionieren, aber das muss natürlich auch richtig interpretiert werden. Von daher wäre eine SW toll, die das schon "aufbereitet". Ist da eine bekannt ?
 
Zuletzt bearbeitet:
APIPA Adressen sind ja aus dem Bereich 169.254.0.0/16. Mag wohl eine von denen sein.

Also Paketscans bzw. den Netzwerktraffic mitschneiden kann Wireshark sehr sehr gut, nur muss man auch damit umgehen können und das auch interpretieren können. Der zeigt dir halt alle Pakete auf dem jeweiligen Interface an.

Schau dann vielleicht auch mal auf dem ProCurve, ob der irgendwas auf seinen Ports meldet, ggf. gibts da massenhaft Anfragen (Broadcast oder Multicast bzw. verwaiste Pakete deren TTL noch nicht erreicht ist) die angezeigt werden. Zumindest die größeren ProCurves können das (5406/5412/2848 etc)
 
Das Kabel in die 2. Etage hängt das am HP oder direkt an der Fritzbox?
 
So wie ich das verstanden hab hängt das am ProCurve, geht in die Dose und dann durch die Wand nach oben....
 
Richtig, Etage 2 hängt am procurve. Nun ist es aber prompt erneut passiert.
Ich habe nun Etage 2 mal direkt an die Fritzbox gehangen -> ohne Änderung
ipconfig liefert (Ausschnitt):

Code:
 Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Physische Adresse . . . . . . . . : 14-DD-A9-E9-CE-B6
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv6-Adresse. . . . . . . . . . . : 2003:d8:53d0:1120:2cd1:473d:5d98:dcb3(Bevorzugt)
   Temporäre IPv6-Adresse. . . . . . : 2003:d8:53d0:1120:a0d6:2741:98a3:7700(Bevorzugt)
   Verbindungslokale IPv6-Adresse  . : fe80::2cd1:473d:5d98:dcb3%8(Bevorzugt)
   IPv4-Adresse (Auto. Konfiguration): 169.254.220.179(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . . : fe80::be05:43ff:fe40:5cc9%8
   DHCPv6-IAID . . . . . . . . . . . : 135585193
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1D-D9-06-35-14-DD-F9-E9-CE-B6
   DNS-Server  . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Tunneladapter isatap.{69A411EE-F06B-494E-B6AA-353089AED3DE}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft ISATAP Adapter
   Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter LAN-Verbindung* 10:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Teredo Tunneling Adapter
   Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Netzwerkadapter meldet: nicht identifiziertes Netzwerk (nicht "Netzwerkkabel entfernt" o.ä.)
Geholfen hat dann letztendlich wieder: Ein Kabel von Dose2ETG_an direkt zu Dose2ETG_ab zu verbinden
 
Zuletzt bearbeitet:
Zurück
Oben