DS6750/DS7700 und Fritzbox vs. Switch

[26196008]

Hallo zusammen,

ich habe folgendes Problem.

Meine EMZ 561-MB24 wurde lange mit einem DS6750 betrieben, aber da ich immer wieder die Netzwerkverbindung zum Übertragungsgerät verloren habe und diese Störung nur über einen Reset am Wählgerät beheben konnte, habe ich mir ein DS7700 zugelegt.

Nachdem das neue DS7700 da war habe ich es direkt eingebaut und nach ein paar Stunden war die Verbindung wieder weg :-(

Daraufhin habe ich den Verkäufer kontaktiert und er gab mir den Rat, dass ich meine Infrastruktur vereinfach soll und das Wählgerät beispielsweise direkt an meiner Fritzbox anschließen soll anstatt an meinem Switch "Lancom GS-2326P".

Diesen Rat habe ich befolgt und tatsächlich blieb die Verbindung Tagelang ohne Störung. Dies habe ich mehrfach auch mit neuen Kabeln usw. reproduzieren können.

Somit war für mich klar, dass es nicht am Wählgerät und auch nicht an der EMZ liegt. Also blieb nur die Option, dass wohl mein Switch einen Defekt hat.

Also habe ich mir einen neuen Switch "Unifi USW-24-PoE" zugelegt.

Kaum war der Switch da und alles getauscht, habe ich das Wählgerät an dem neuen Switch angeschlossen.

Und nur das verrückte, nach ein paar Stunden war wieder das Wählgerät gestört und eine Verbindung war nicht möglich :-(

Das kann doch echt nicht wahr sein, was läuft denn da falsch? Muss man bei einem "Managed Switch" etwas bestimmtes einstellen?

Ich hoffe mir kann jemand helfen. Ich möchte eigentlich alles über den Switch laufen lassen und nicht den Umweg über die Fritzbox nehmen, da die Fritzbox auch nicht mein Router ist, sondern nur zur Telefonie genutzt wird.

Viele Grüße
Marc

[mh__]

Benutzt Du den Switch auch wie einem Managed Switch? Der deaktiviert den Port vielleicht aufgrund irgendeines Filters, das würdest Du dann sicher im Log des Switches sehen?

[ah88985]

Ich hatte das gleiche Problem mit dem DS7700, regelmäßig Verlust der Netzwerkverbindung, sobald noch ein zusätzlicher Switch beteiligt ist. Seit dem das UEG direkt an der Fritzbox hängt, funktioniert es stabil.

Was Du versuchen kannst: Die Geschwindigkeit fest auf 10MBit einstellen, falls das dein Switch kann, meiner leider nicht.

[ssb-security]

Ein Switch schleift doch einfach nur durch. Selbst bei einem "managed Switch" ist Stand Auslieferung alles offen. Es wird wohl so sein wie Du schilderst, aber Sinn macht das für mich überhaupt nicht.

[26196008]

Vielen Dank für Eure Antworten. Leider ist es wirklich so :-(

Filter habe ich auf dem Port nicht aktiv.

Das UEG habe ich sogar extra an einem Port angeschlossen, welcher kein PoE unterstützt.

Ich könnte den Port am Switch 10MBit drosseln und hätte noch die Auswahl zwischen FDX und HDX. Welches Einstellung soll ich testen?

[ssb-security]

Half oder Full Duplex, was soll das bringen?

[Ollik]

Es bleibt die Frage nach den Logs des Switches offen...

VG Olli

[funkistnichtalles]

Wenn das WG bedarfsgesteuert programmiert ist, kann es ohne weiteres sein, dass der Port schlafen geht. Dann kommts wohl noch auf die Routineprogrsmmierung an und dann kommen dann so fuzzelmeldungen mit ein paar Bits, die den Port nicht zum aufwachen bewegen wollen.
Warum wird das WG nicht direkt angeschlossen?
Wenn die FB notstromgestützt wird und der Switch nicht, was glaubst was dann geschieht.? Was ist das denn überhaupt für eine Installation? Als Errichter würde ich sowas nicht durchgehen lassen, zumindest nicht, ohne dass du mich aus jeder Haftung aufgrund deiner Wünsche freistellst.
Für sowas würde ich nie meine Zertifizierung aufs Spiel stellen…
Wenn mit zweitem Ü -weg gearbeitet wird, sieht es anders aus, dennoch ist in jedem Ü-weg der kürzeste Weg zu wählen…

[26196008]

Also ich habe nun das UEG erneut an den Switch angeschlossen und diesen auf 10MBit FDX gestellt. Welche Auswirkung FDX (Full Duplex) oder HDX (Half Duplex) hat, kann ich nicht sagen. Sobald das UEG weg ist, werde ich die entsprechenden Logs nachreichen. Die alten finde ich leider nicht.

@funkistnichtalles: Ich finde deinen Beitrag vollkommen unangebracht. Warum diese Aufregung deinerseits, wo du doch nicht für meine Umgebung herhalten musst. Ich glaube, dass meine Umgebung weit besser aufgestellt ist als von vielen anderen. Natürlich ist nicht nur die Fritzbox durch eine USV geschützt, sondern alles Relevante, um die notwendige IT in Betrieb zu halten. Weiterhin muss die USV nur wenige Momente alles überbrücken, da ich einen dicken Batteriespeicher im Keller habe und mein gesamtes Haus ca. 80% des Jahres autark ist. Zurück zum Thema. Auch vorhandene Routineprogrammierung lassen den Port nicht aufwachen. Dies würde auch nicht das unterschiedliche Verhalten zwischen Fritzbox und anderen Switch erklären.

[26196008]

Zwischenstand: Bislang kein Ausfall :-)

[ssb-security]

Tja, man muss nicht alles erklären oder verstehen. Manchmal funktioniert es einfach und gut ist es.

[26196008]

Hätte ich mal nichts geschrieben :-(

21.09.23 at 11:54:39: "DS7700 absent"

Leider ist es wieder weg.

Im log habe ich mal ein grep auf den genutzten Port gemacht:

Code:

USW-24-PoE-UM.6.5.59# cat  messages | grep "Port 17"
Sep 18 15:47:41 USW-24-PoE kern.notice kernel: [784293.020000] Port 17 link up
Sep 18 15:47:41 USW-24-PoE kern.warn kernel: [784293.080000] Port 17 moving from Disabled to Blocking
Sep 18 15:47:43 USW-24-PoE kern.warn kernel: [784295.330000] Port 17 moving from Blocking to Forwarding

Leider keine Einträge von heute.

Und hier die letzten 50 Einträge aus dem Log:

Code:

Sep 20 17:37:32 USW-24-PoE kern.notice kernel: [963672.230000] Port 9 link down
Sep 20 17:37:32 USW-24-PoE kern.warn kernel: [963672.350000] Port 9 moving from Forwarding to Disabled
Sep 20 17:37:33 USW-24-PoE kern.notice kernel: [963673.870000] Port 9 link up
Sep 20 17:37:33 USW-24-PoE kern.warn kernel: [963674.100000] Port 9 moving from Disabled to Blocking
Sep 20 17:37:35 USW-24-PoE kern.warn kernel: [963676.100000] Port 9 moving from Blocking to Forwarding
Sep 20 20:00:12 USW-24-PoE kern.notice kernel: [972231.840000] Port 9 link down
Sep 20 20:00:12 USW-24-PoE kern.warn kernel: [972232.010000] Port 9 moving from Forwarding to Disabled
Sep 20 20:00:15 USW-24-PoE kern.notice kernel: [972235.480000] Port 9 link up
Sep 20 20:00:15 USW-24-PoE kern.warn kernel: [972235.510000] Port 9 moving from Disabled to Blocking
Sep 20 20:00:18 USW-24-PoE kern.warn kernel: [972238.260000] Port 9 moving from Blocking to Forwarding
Sep 20 20:15:08 USW-24-PoE daemon.info : process '/sbin/udhcpc -f -i eth0 -V ubnt -A 10 -s /etc/udhcpc/udhcpc -p /var/run/udhcpc.eth0.pid -h USW-24-PoE' (pid
Sep 20 20:15:08 USW-24-PoE daemon.info : starting pid 7937, tty '/dev/null': '/sbin/udhcpc -f -i eth0 -V ubnt -A 10 -s /etc/udhcpc/udhcpc -p /var/run/udhcpc.eth0.pid
Sep 20 20:15:08 USW-24-PoE user.info : uplink-monitor[383]: uplink-monitor.update(): entering isolated state
Sep 20 20:15:10 USW-24-PoE user.notice syswrapper: ipready.eth0 = 172.16.0.11
Sep 20 20:15:11 USW-24-PoE user.notice syswrapper: ipready.eth0 = 172.16.0.11
Sep 20 20:17:13 USW-24-PoE kern.notice kernel: [973252.880000] Port 9 link down
Sep 20 20:17:13 USW-24-PoE kern.warn kernel: [973253.040000] Port 9 moving from Forwarding to Disabled
Sep 20 20:17:15 USW-24-PoE kern.notice kernel: [973254.530000] Port 9 link up
Sep 20 20:17:15 USW-24-PoE kern.warn kernel: [973254.540000] Port 9 moving from Disabled to Blocking
Sep 20 20:17:17 USW-24-PoE kern.warn kernel: [973257.290000] Port 9 moving from Blocking to Forwarding
Sep 20 21:49:21 USW-24-PoE kern.notice kernel: [978780.990000] Port 9 link down
Sep 20 21:49:22 USW-24-PoE kern.warn kernel: [978781.220000] Port 9 moving from Forwarding to Disabled
Sep 20 21:49:25 USW-24-PoE kern.notice kernel: [978784.740000] Port 9 link up
Sep 20 21:49:25 USW-24-PoE kern.warn kernel: [978784.970000] Port 9 moving from Disabled to Blocking
Sep 20 21:49:28 USW-24-PoE kern.warn kernel: [978787.220000] Port 9 moving from Blocking to Forwarding
Sep 20 22:01:01 USW-24-PoE kern.notice kernel: [979480.900000] Port 19 link down
Sep 20 22:01:01 USW-24-PoE kern.warn kernel: [979480.990000] Port 19 moving from Forwarding to Disabled
Sep 20 22:01:06 USW-24-PoE kern.notice kernel: [979486.120000] Port 19 link up
Sep 20 22:01:07 USW-24-PoE kern.warn kernel: [979486.240000] Port 19 moving from Disabled to Blocking
Sep 20 22:01:09 USW-24-PoE kern.warn kernel: [979488.240000] Port 19 moving from Blocking to Forwarding
Sep 20 22:01:21 USW-24-PoE kern.notice kernel: [979500.880000] Port 19 link down
Sep 20 22:01:21 USW-24-PoE kern.warn kernel: [979500.990000] Port 19 moving from Forwarding to Disabled
Sep 20 22:02:05 USW-24-PoE kern.notice kernel: [979544.440000] Port 19 link up
Sep 20 22:02:05 USW-24-PoE kern.warn kernel: [979544.490000] Port 19 moving from Disabled to Blocking
Sep 20 22:02:08 USW-24-PoE kern.warn kernel: [979547.240000] Port 19 moving from Blocking to Forwarding
Sep 21 08:15:10 USW-24-PoE daemon.info : process '/sbin/udhcpc -f -i eth0 -V ubnt -A 10 -s /etc/udhcpc/udhcpc -p /var/run/udhcpc.eth0.pid -h USW-24-PoE' (pid
Sep 21 08:15:10 USW-24-PoE daemon.info : starting pid 28343, tty '/dev/null': '/sbin/udhcpc -f -i eth0 -V ubnt -A 10 -s /etc/udhcpc/udhcpc -p /var/run/udhcpc.eth0.pid
Sep 21 08:15:11 USW-24-PoE user.notice syswrapper: ipready.eth0 = 172.16.0.11
Sep 21 08:55:06 USW-24-PoE user.info : mca-monitor[389]: mca-monitor.do_monitor(): collector not responding, elapsed=1018791 (max=300)
Sep 21 08:55:06 USW-24-PoE user.notice syswrapper: kill-inform-collector. reason: inform-collector not responding
Sep 21 08:55:06 USW-24-PoE daemon.info : process '/bin/inform-collector' (pid 390) exited. Scheduling for restart.
Sep 21 08:55:07 USW-24-PoE daemon.info : starting pid 31344, tty '/dev/null': '/bin/inform-collector'
Sep 21 08:55:08 USW-24-PoE daemon.info : process '/bin/inform-collector' (pid 31344) exited. Scheduling for restart.
Sep 21 08:55:08 USW-24-PoE daemon.info : starting pid 31347, tty '/dev/null': '/bin/inform-collector'

Mir gehen die Ideen aus :-(

[Feuermelder]

Definiere weg.

Was sagt das ÜG? Ethernetstörung oder Verbindung zum Wachdienst gestört?

Also sind die Link LEDs auf dem ÜG auch aus?

Netzwerkleitung schonmal getauscht?

[26196008]

(21-09-2023 12:13)Feuermelder schrieb:  Netzwerkleitung schonmal getauscht?

Ich habe schon alles getauscht. Siehe Hauptthema

Hier die Logs von heute:

[Feuermelder]

Kannst du in dem Moment, wenn sich das ÜG verabschiedet hat auf das ÜG zugreifen? Oder drückst du nur Reset auf der Platine?

Mit dem Debugmodus hast du dich aber noch nicht befasst? Wenn man dort z.B. einen Trace nicht wieder beendet bzw. das ÜG neustartet, dann läuft irgendwann ein Puffer voll und das ÜG stürzt ab.

Wenn du schon alles durchgetauscht hast, dann kann es ja ggf. auch ein anderes Gerät im Netzwerk sein, was das ÜG zum Absturz bringt, du kannst ja probeweise mal die DOS-Erkennung aktivieren.

[26196008]

Über LAN komme ich nur dran, wenn ich Reset auf der Platine drücke.

Ich habe da noch nicht versucht über USB zuzugreifen. Könnte ich da über USB nach dem Absturz ohne Reset mehr Inforationen über Debug rausbekommen? Habe mit Debug noch nicht gearbeitet.

Ich schalte heute mal DOS-Erkennung an. Vielleicht steht dann mehr im Log

[funkistnichtalles]

Eine relativ einfache Erklärung für unkontrolliertes Aussteigen von Netzwerkkomponenten sind Doppeladressen.
Das würde ich immer prüfen, denn in Netzwerken kann so einiges passieren, was im Nachgang nicht nachvollziehbar ist.
Bleibt das ÜE nach dem Ausstieg pingbar?

---

Nachtrag: eine weitere Fehlerbildung könnten zwei sich überlappende DHCP server im System sein. Der TE sprach von FB und lancom.
Weiterhin würde ich die ip des Wählgeräts mal ändern und ans obere Drittel des Netzwerkes bringen.
Pinge vorher die freie Adresse an, um sicher zugehen ,dass die auch unbenutzt ist.

[26196008]

(22-09-2023 05:54)funkistnichtalles schrieb:  Eine relativ einfache Erklärung für unkontrolliertes Aussteigen von Netzwerkkomponenten sind Doppeladressen.
Das würde ich immer prüfen, denn in Netzwerken kann so einiges passieren, was im Nachgang nicht nachvollziehbar ist.
Bleibt das ÜE nach dem Ausstieg pingbar?

Ein anderes Netzwerkgerät, welches die IP vom ÜE nutzen möchte oder irgendwelche Geräte welche die gleichen IPs nutzen wollen? ÜE ist nicht mehr pingbar, nur darüber bekomme ich es so schnell mit. Habe aktuell eine Ping-Überwachung gebaut, welche mich benachrichtigt, wenn ein Ping nicht mehr möglich ist.

(22-09-2023 05:54)funkistnichtalles schrieb:  Nachtrag: eine weitere Fehlerbildung könnten zwei sich überlappende DHCP server im System sein. Der TE sprach von FB und lancom.
Weiterhin würde ich die ip des Wählgeräts mal ändern und ans obere Drittel des Netzwerkes bringen.
Pinge vorher die freie Adresse an, um sicher zugehen ,dass die auch unbenutzt ist.

DHCP-Server habe ich nur einen aktiv.
IP ist aktuell 172.16.0.50 und fest vergeben und nicht über DHCP. Was meinst du mit oberes Drittel

Fraglich bleibt weiterhin, warum es an der FB nicht abstürzt aber an dem Lancom oder Unifi Switch schon.

FB, Lancom und Unifi haben alle DHCP aus. DHCP kommt von meiner Sophos XG

[26196008]

Erneuter Ausfall um 17:17:15

Auch DoS hat nichts neues im Log gezeigt:


Ideen?

[Feuermelder]

Wenn du eine Fritzbox nutzt, dann richte doch mal den Gastzugang auf Lan Port 4 ein und steck das DS dorthin. Dann ist das DS in einem eigenen Netzbereich, der von deinem restlichen Netzwerk isoliert ist. Musst nur aufpassen, dass du bei den Filtereinstellungen für den Gastzugang die Filter rausnimmst, da du sonst die Notrufzentrale nicht erreichen kannst.

Und verbinde dich mal mit Usb, wenn das ÜG abgestürzt ist und drück nicht immer stumpf Reset.

Ansonst mal die Spannungsversorgung geprüft?