Plötzliche massive Verbindungsprobleme primär mit Tischtelefonen

vieledinge

Customer
Mitglied seit
12. Mai 2021
Beiträge
141
Hallo zusammen,

wir haben hier seit gestern Mittag einen komischen Effekt, den wir nicht gegriffen bekommen.

3CX pro on Premise (Windows-Host, virtuell), ca. 150 Nutzer, davon ca. 60 Tischtelefone. Alles im gleichen physischen und logischen Netz.
Gemischte Clients (Smartphone, Windows-Client, Browser-Client, Tischtelefone (primär Yealink T54W, aktuelle Firmware).
Keine Updates oder Änderungen am Netzwerk in den letzten Tagen.

Seit gestern Nachmittag verlieren die Yealinks sporadisch die Verbindung zum 3CX-Host und melden "Kein Service". Genau so sporadisch reconnecten sie sich wieder und das Spiel geht dann irgendwann von vorn los. Kompletter Neustart der Telefone hilft meist nur temporär.

Vermutlich ist das Verhalten bei den Softclients ähnlich, man sieht es da nur nicht so bzw. reconnecten die sich schneller wieder.

Der 3CX-Server wurde schon komplett neu gestartet. Alle Indikatoren in 3CX sind grün. Auffällige Meldungen im Log gibts keine.

Irgend einer ne Idee, wo man da noch suchen könnte?
 
Hallo @vieledinge ,

wer, bzw. was hat denn alles Zugriff auf das Netzwerk? Nicht das jemand die neue Staffel "Lustige Katzenbabyvideos" streamt...

Ansonsten mal die Logs auf ausführlich laufen lassen und dann checken.

Viel Erfolg!
 
Hallo @vieledinge ,

wer, bzw. was hat denn alles Zugriff auf das Netzwerk? Nicht das jemand die neue Staffel "Lustige Katzenbabyvideos" streamt...
Unwahrscheinlich. Die Firewall limitiert auf 2MBit/Client. Selbst wenn das alle machen würden wäre der Hausanschluss deutlich früher ausgelastet, als der interne Backbone (1GBit am Platz, 20/40GBit auf den Switch-Linkstrecken). Die Switche sind clean, zur Sicherheit neu gestartet, keine auffälligen Meldungen, keine Fehler, keine Änderungen an den VOIP-Priorisierungen.

Ansonsten mal die Logs auf ausführlich laufen lassen und dann checken.

Viel Erfolg!

Habe ich mal gemacht. Bis jetzt nichts Verdächtiges.
 
Hat sich geklärt. War doch nen technisches Problem im Netzwerk. :(
 
Ja, ließ sich relativ einfach lösen mit Ziehen des richtigen Steckers... :rolleyes:
 
  • Haha
Reaktionen: bitn2
Großartig, ja manchmal ist die Lösung so einfach.
 
Moin zusammen,

ich will mich zu dem Thema dann doch nochmal melden. Weil das oben genannte Kabel wars dann doch nicht. Da hatte der Kollege nur zufällig zum richtigen Zeitpunkt den Stecker gezogen. Und sich zu früh gefreut...

Und weil ich im Forum einige Threads mit ähnlichen Problemen gefunden habe. Vielleicht hilfts ja irgendwem.

Das ganze Thema hat uns die letzten beiden Wochen recht ausgiebig beschäftigt. Der Effekt trat alle paar Tage für mehrere Stunden auf und verschwand genauso ominös, wie er gekommen war. Wenn er da war konnte man über die Softclients noch einigermaßen intern telefonieren. Extern nur mit Einschränkungen, weil auch die SIP-Trunks unregelmäßig wegflogen (DNS-Fehler) und sich reconnecteten. Die Tischtelefone sind dauerhaft Amok gelaufen (Connect/Disconnect) und waren in der Zeit quasi nicht brauchbar.

Wir waren dann von einem störenden Gerät ausgegangen (wir haben nen relativ großen F&E-Bereich, wo gerne mal was ans Netz genommen wird, und den wir aus div. Gründen auch leider nicht physisch oder virtuell in ein eigenes LAN sperren können). In den Switch-Logs war nichts auffälliges zu finden, auch sonst war nichts Verdächtiges (doppelte IP- oder MAC-Adressen, komische Dienste) ermittelbar. Also haben wir nach und nach die einzelnen Netzwerksegmente vom Core-Switch abgeklemmt, um zu schauen, wann wieder Ruhe einkehrt. Den Gefallen hat uns die Ruhe nicht getan. Daran lags nicht.

Nächste Idee war dann mal der Umzug der 3CX-Windows-VM auf nen anderen VM-Host. Danach ging das Kino erst richtig los, die Anlage war quasi komplett unbenutzbar. Ok, also neue VM wieder runter, alte VM wieder hochfahren. Das Kino blieb, nicht mehr benutzbar.

Nachdem wir uns das Ganze dann nochmal mit unserem Betreuer angeschaut haben und da die gleiche Ratlosigkeit herrschte wie bei uns haben wir uns dann für ein Neuaufsetzen der Server-VM entschieden. Mittelfristig wollten wir eh auf die Linux-Variante wechseln, also haben wir das dann adhoc so angegangen.

- Linux-VM aufgesetzt, mit identischer IP und Hostname, etc.
- 3CX installiert
- 3CX-Backup der Windows-Maschine eingespielt.

Bäm! Läuft!

Die SIP-Trunks gingen direkt online und nach einigen Minuten hatten sich auch alle Telefone reconnected. Paar einzelne haben wir nochmal aktiv neu provisioniert, weil bei denen die Anzeigen noch in der falschen Sprache standen, was ich aber bei dem Tag Kino jetzt nicht überbewerten würde.

Mittlerweile läuft es ca. 1 Tag ohne die geringsten Mucken.

Woran lags? Wir wissen es nicht. Vermutlich ist irgendwas im Netzwerkstack der Windows-VM oder des Windows-3CX-Dienstes durcheinander. Wobei alle lokalen Analysen (Pings, TraceRoutes, DNS-Resolves) immer alle ok waren. Schadsoftware können wir auch ausschließen. Noch sind die VMs vorhanden. Mal sehen ob wir nochmal Zeit und Lust zur Leichenfledderei haben und uns das nochmal vornehmen. Aktuell muss ich erst mal alles abarbeiten, was die letzten Wochen wegen dem Mist liegengeblieben ist.

Ach ja: Ich könnte paar gedrückte Daumen gebrauchen, dass es jetzt weiterhin und dauerhaft ruhig bleibt.
 
Interessant! Wir nutzen bei unseren Kunden grundsätzlich die Linux Variante. Windows scheint da problematischer zu sein.
 
Frage: was für ein Hypervisor wurde und wird verwendet?
 
Interessant! Wir nutzen bei unseren Kunden grundsätzlich die Linux Variante. Windows scheint da problematischer zu sein.
Den Verdacht habe ich mittlerweile auch. Zum Zeitpunkt der Einrichtung war noch nicht klar, ob wir 3CX ggfs. an den Exchange andocken. Oder es war irgend nen anderes Feature, was nur mit Windows geht. Deshalb hatten wir uns damals für Windows entschieden. Mittlerweile ist das aber obsolet, deshalb jetzt auch der Wechsel.
 
Windows-Server mit HyperV-Rolle. Zeitsynchronisation sollte im Hostmanager aus sein. Muss ich nochmal schauen, kann sein, dass das beim Umziehen der VM irgendwo durchgerutscht ist. Wäre dann ne mögliche Ursache.
 
Belibt immer noch die Frage offen: Welche Version vom Windows Server wird verwendet (zum dritten mal)?
 
Win2012R2 und Win2016 als HyperV-Host, Win10 als Gast.

Ich tippe immer mehr auf die Zeitsynchronisation, wahrscheinlich ist das beim Umzug der VM übersehen worden. Mal sehen ob ich mal ein passendes Zeitfenster finde, um das gegenzutesten.
 

Statistik des Forums

Themen
44.414
Beiträge
232.721
Mitglieder
78.331
Neuestes Mitglied
b2daniel