Unregelmäßiger Ausfall des Internets/Teilen des LANs

[TorenAltair]

Hast Du den DHCP-Server auch im TPLink SG1428PE geprüft?

 

[chrigu]

Sind bei den Aussetzern auch powerline Adapter im Spiel

 

[Bon3]

Irgend einen ipv6 DHCP noch am laufen oder so?
Ich würde eher einen Zabbix, Uptimekuma oder smokeping auf das problem werfen.
Alles und seine Mutter im lan permanent pingen, und ins Internet in verschiedenste Richtungen+ auflösen über DNS und IPs direkt + ein paar ipv6 zum abrunden.
Dann kriegt man eher einen Zeitlichen und örtlichen tip wo das problem sein könnte,

 

[TomTDooley]

Vielleicht liegt auch nur ein DNS-Problem vor?

Betriebssysteme haben einen DNS-Cache, der vielleicht erklärt, wieso einige Seiten funktionieren und manche nicht.

Die To-Do-Prüfliste ist ganz schön gewachsen durch die vielfältigen Tipps.
Bis die alle abgearbeitet sind, von Gerät zu Gerät, dauert wohl einen Augenblick.

 

[st_schroeder]

Switch ist im reinen Switch Betrieb.
Keine Powerline.
DHCP wäre aus den beiden fritzboxen oder dem Switch denkbar, aber sind als reine APs bzw switch konfiguriert.
Die drei genannten Programme sind ein guter Ansatz, so in der Art hatte ich das schonmal vor, fehlte nur der richtige Ansatz für die benötigte Software.
Der Einfachheit halber habe ich gerade den rechten Strang umgeändert und die Fritzbox Dort ist nun als kaskadierter Router unterwegs, sodass der DG Router die Geräte dort nicht mehr sieht.

DNS: Auch ein direkter Aufruf von IPs geht ins leere.

Gestern Abend mit Intrace und dem Smartphone spiegel.de und Google.De geprüft - Spiegel ging so durch und Google kam keine Antwort vom Router.

 

[redjack1000]

Der Einfachheit halber habe ich gerade den rechten Strang umgeändert und die Fritzbox Dort ist nun als kaskadierter Router unterwegs, sodass der DG Router die Geräte dort nicht mehr sieht.

Dann warten wir mal ab.

Cu
redjack

 

[Sebbi]

• Teile des Internets nicht erreichbar, d.h. manche Apps und Seiten gehen, manche nicht (Vermutung: IPv4 geht und IPv6 nicht oder sowas...)
• Router GUI aus Teilen des LANs nicht erreichbar trotz funktionierender Internetverbindung
• generell ab und an "komisches" Verhalten im Netz; z.B. sehr hohe Latenzen, kuriose Fehlermeldungen in IoT Geräten und Netzwerkdruckern...

alle 3 Punkte interagieren miteinander und das kann durchaus auf das missbrauchte Telefonkabel zurückzuführen sein, auch wenn das bisher funktionierte und quasi nicht bewegt wurde.
Das kann durch chemische Änderungen im Kabel etc. die durch die lange Liegezeit und Oxidation hervorgerufen werden oder dadurch das ein anderer Anwendungszweck als vorgesehen genutzt wird (höhere Signalfrequenzen, dadurch Elektromigration etc)

Die Folge können jetzt Störsignale sein, die deine Komponenten aus den Tritt bringen.
Zum Testen kannst verlege mal wild für ein paar Tage ein CAT6a Kabel und überbrücke damit das Telefonkabel und prüfe, ob der Fehler weiterhin auftritt.

Ansonsten könnte aber auch ein anderes Netzwerkgerät bei dieser Fehlersymtomatik querschießen, was aber bei den vielen Geräten richtig bescheiden zu diagnostizieren ist.


DHCP / DNS ist theoretisch ein guter Ansatz, aber widerspricht dann dem Punkt "Router GUI aus Teilen des LANs nicht erreichbar" und dem Punkt "generell ab und an "komisches" Verhalten im Netz; z.B. sehr hohe Latenzen, kuriose Fehlermeldungen in IoT Geräten und Netzwerkdruckern..."

 

[st_schroeder]

Zwischenstand: Bisher keine Ausfallerscheinungen. Grundsätzlich scheint "gefühlt" alles etwas schneller im Netz zu sein - nichts empirisches, aber man meint, alles reagiert etwas flotter. Sollte sich das bewähren, wir der AP von TP-Link durch einen weiteren AP von Fritz ersetzt; ich kannte das Mesh nur aus seiner Anfangszeit, aber das scheint ja wirklich ordentlich zu laufen.

@Sebbi : Das Telefonkabel sehe ich sicherlich auch als Schwachstelle im System an; aber als Ursache für die genannte Problematik schließe ich es nahezu aus. EM bei einem 0,6mm Leiter sehe ich nicht (wenn ich das noch richtig in Erinnerung habe, ist EM nicht von der Frequenz sondern der Stromdichte abhängig). Grundsätzlich habe ich im privaten Bereich gute Erfahrungen bei Bestandsanlagen und "missbrauch" von Telefonleitungen gemacht; siehe auch http://bedienungsanleitung.elektronotdienst-nuernberg.de/impedanz.html
Hier würde ich auf erste Fehler in der Übertragung tippen, wenn z.B. das alte Kupfer etwas spant - und die sollten ja in einem der beiden Boxen zu sehen sein.
Dein Vorschlag mit dem Kabel mal eben dazwischen ist leider nicht so schön umsetzbar, da der Weg durchs Treppenhaus etc. mal schnell 30m und mehr sind und dazwischen eine Brandschutztüre hockt.

Danke schonmal - eure Rückmeldungen helfen mir ungemein, altes Wissen neu aufzufrischen und man kommt gleich wieder in so ein Feeling von vor 25 Jahren, wo man sich in alles reingefuchst hat und nur vor den Kisten saß...

 

[Sebbi]

Dein Vorschlag mit dem Kabel mal eben dazwischen ist leider nicht so schön umsetzbar, da der Weg durchs Treppenhaus etc. mal schnell 30m und mehr sind und dazwischen eine Brandschutztüre hockt.

Frage ist, wie sproadisch nun diese Ausfälle sind. Die 30 m wären kein Problem. Die Bandschutztür hingegen schon. Wenn das jede Woche auftriit kann dann man auch mal Fenster auf, Kabel durch und Fenster verkeilen und Handtücher auslegen für die Woche machen.

(wenn ich das noch richtig in Erinnerung habe, ist EM nicht von der Frequenz sondern der Stromdichte abhängig).

auch höhere Frequenzen tragen zur EM und anderen chemischen Prozessen bei, weil sich die Stromstärke durch die höhere Frequenz auch erhöht

https://forums.tomshardware.com/threads/better-understanding-electromigration.289307/

Spoiler: Erklärung

The answer is actually simpler than you think.... the short of it is, increasing frequency also increases the total current through the device, hence, the metal lines will experience higher current density and higher electromigration degradation.

Here is the explanation .... those who have watch me post know I am keen on the td=CV/I, where td is gate delay, C is total capacitance, V of course is voltage, and I is current or Idsat, drive current. This is a fundamental equation describing the max switching speed of a device. However, in this form and this way of thinking td is the dependent variable and is a function of C, V, and I -- all three of which are design parameters, what happens after we have optimized the process and nothing changes any longer --- then we rearrange this equation and, in this case, let's look at I as the independent variable:

I = CV/td or CV*(1/td)

But 1/td is one over time which is frequncy, f. So ---

I = CV*f

Thus, since C is fixed by the oxides, wires, and transistors in the CPU, V is dialed by you the user, and f is set by the clock generator, then I is a direct function of frequency AND voltage.

In the link above, electromigration lifetimes are modeled by Black's equation (see link above):

tf = A * (1/J)^n * EXP(Ea/kT)

A is material dependent, J is the current density which is I/unit area cross section of the wire, n is a emperically determined exponent, Ea is activation energy, k is the Boltzmann constant, and T is temperature. Key here is current density J as the current goes up so does the electromigration factor.

So really, the increase of electromigration with frequency is no more than an increase in current driven by the frequency generator. Pretty simple.

Side note: Validate my I = CV*f equation, recall that I also post many times that the equation for dynamic power is P=CV^2*f , well with a little algrebra check this out ---

P = I*V ===> fundamental electrical power equation.

Substitute the expression for current as a function of frequency from my argument above,

P = (CV*f)*V = C*V^2*f wow, now we see where the dynamic power equation comes from and that power really goes as a cube of the 'speed fundamental varibles --- 2 orders in voltage and 1 order in frequency.

und

https://www.synopsys.com/glossary/what-is-electromigration.html

 

[hildefeuer]

Eben den langen Threat gelesen.
Wenn der Sagencom vom selbst neu startet, =Netzteil Fehler. Falls Netzteil zur Hand tauschen.
Wenn Webinterface selbst am LAN des Sagemcom nicht erreichbar ist, gehört der ausgetauscht, kann aber auch am Netzteil liegen.
Auch wenn nach Neustart erst mal alles wieder läuft, deutet in diese Richtung.

Alle Gedanken darüber, warum denn nun einige Dinge noch gehen, andere nicht mehr, sind dann sinnlos.

Habe selbst öfters hinter solchen und ähnlichen Fehlern hinterher gesucht.
War nicht immer das Netzteil. Manchmal auch Elko auf Platine.
Findet man schnell mit Kältespray und Multimeter. Unter Last Spannung messen und Elkos ein sprühen und gucken ob Spannung wackelt.
Das es am Telefon-Kabel zu LAN liegt glaube ich nicht. Dann würde der Strang ausfallen und der rechte ohne Fehler laufen.
Ich hatte so Router (Acror) bei dehnen das WLAN lief und LAN ports nicht. Oder (7490)WLAN nur langsam und keine DSL Synchro usw.

 

[Sebbi]

Wenn der Sagencom vom selbst neu startet, =Netzteil Fehler. Falls Netzteil zur Hand tauschen.
Wenn Webinterface selbst am LAN des Sagemcom nicht erreichbar ist, gehört der ausgetauscht, kann aber auch am Netzteil liegen.

ich gebe dir noch eine Möglichkeit:

korrupte Ethernetpakete oder solche, die nicht dem Standard entsprechen von einen IoT Gerät oder Switch.
Hatte mit früheren FritzBoxen immer Probleme, wenn man uPNP nicht überall auf den Netzwerkgeräten und in Windows den uPnP Dienst deaktiviert hat ( was man so oder so immer machen sollte da uPnP eine Sicherheitslücke sonders gleichen ist ), das wenn auf der DSL Seite es zu höheren CRC Fehlerraten gekommen ist durch irgend ne Störung, das das Webinterface immer träger wurde und dann die FB irgenwann gar nicht mehr erreichbar war.

Ebenso hat auch ein unmanaged TP-Link Switch schon EthernetRahmen produziert, die andere Netzwerkgeräte gestört haben in gewissen Konstallationen und auch zum Absturz brachten.

 

[norKoeri]

Vermutung: IPv4 geht und IPv6 nicht oder sowas.

Ohne den Thread irgendwie weiter verfolgt zu haben, also wohl eher für passive Leser, die über eine Internet-Suche hier vorbeistolpern. Das kannst Du im Fehlerfall testen, also Webseiten die definitiv nur über eine IP-Version angesprochen werden können, z. B.: ipv4.icanhazip.com und ipv6.icanhazip.com.

Router GUI aus Teilen des LANs nicht erreichbar trotz funktionierender Internetverbindung

Direkt über die IPv4-Adresse also nicht über dessen Domain-Namen? Dann hast Du kein funktionierendes IPv4. Auch die Router-GUI über IPv6? Quasi alle Router bieten das inzwischen.

Gestern Abend mit Intrace und dem Smartphone spiegel.de und Google.De geprüft - Spiegel ging so durch und Google kam keine Antwort vom Router.

Dann hast Du kein funktionierendes IPv6.
Ich befürchte glatt, dass Du zwei Probleme hast: (1) Ab und an kein IPv4. (2) Ab und an kein IPv6.

Workaround wäre, den DG Router bis auf das direkte Routing zu entlasten und DHCP etc. von den Fritzboxen im jeweiligen Strang vergeben zu lassen; diese selbst per feste IP einzubinden.

Router-Kaskade? Keine gute Idee … und ehrlich auch kein Workaround. Wenn Du einen „Strang“ nicht sicher unter Kontrolle hast, dann besser direkt vor den Router einen Switch mit Port-, Client-Isolation bzw. DHCP-Snooping, damit Du keine DHCP-Starvation hast.

 

[hildefeuer]

@Sebbi
"das wenn auf der DSL Seite es zu höheren CRC Fehlerraten gekommen ist durch irgend ne Störung, das das Webinterface immer träger wurde und dann die FB irgenwann gar nicht mehr erreichbar war."
Er hat Glasfaser von DG. Nix dsl.
DG hat bei ipv 4 einen Router davor. Eine öffentliche ipv4 gibt es nicht. Wenn ipv4 ausfällt, müste auch Telefon ausfallen, weil der Sip Account über ipv4 läuft.

 

[Sebbi]

@hildefeuer

ich bezog mich auf deine Aussagen, wie das Gerät gestört sein könnte. Wie ich am Beispiel der FB erläutert habe, muss das nicht unbedingt wie von dir geschildert auf ein defektes NT oder ein Defekt vom Gerät hindeuten, wenn die Management GUI über das Netzwerk nicht erreichbar ist.

Das kann auch durch Störungen im Netzwerk verursacht werden, die eben das Gerät aus dem Tritt bringen.

Das war allgemein geschildert und NICHT speziell auf die Situation vom TE bezogen.

zudem bitte nicht aus dem Zusammenhang das reißen, denn die Situation der FB war damals so:

CRC Fehler auf der DSL + uPnP Pakete auf der LAN seite brauchten den Webserver auf der FB zum abschmieren!