Guten Tag,
ich hoffe, der Post ist hier an der richtigen Stelle und der Text wird nicht zu lang.
Ich erkläre zunächst die Struktur, die wir aufgebaut haben:
Wir betreiben ca. 1200 Yealink T57W Telefone in 25 Außenstellen.
Jede Außenstelle verfügt über einen SBC, und die Telefone befinden sich dort im VLAN 160 (unser Telefon-VLAN).
Auch hier in der Zentrale sind etwa 150 Telefone in diesem VLAN.
Die 3CX-Anlage selbst liegt in einer DMZ.
Das Regelwerk zu der VM in der DMZ ist soweit korrekt. SIP-ALG ist auch deaktiviert.
Die Telefone funktionieren grundsätzlich problemlos:
Registrierung, Telefonie und Provisionierung laufen einwandfrei.
Das Problem:
Vereinzelt melden Anwender, dass ihr Telefon plötzlich kein Netzwerk mehr hat.
Fehlermeldung: "No Service" danach "IP-Adresse wird bezogen"
Dieses Phänomen tritt mittlerweile häufiger auf.
Früher, mit älteren Firmware-Versionen, gab es dieses Problem nicht.
Betroffen sind immer wieder andere Telefone – es gibt keine festen Muster oder bestimmte Geräte.
Da wir einen RADIUS-Server (Aruba ClearPass) einsetzen, können wir nachvollziehen, wo das Problem auftritt.
Dort sehen wir, dass einige Telefone sich sporadisch neu anmelden.
Es scheint, als würde sich das Telefon „netzwerkseitig“ zurücksetzen.
Anschließend durchlaufen die Telefone erneut die RADIUS-Authentifizierung und beziehen eine neue IP vom DHCP-Server.
Während dieser Zeit sind sie jedoch nicht erreichbar.
Besonders problematisch wird es, wenn dies während eines Gesprächs passiert!
Beobachtungen:
[09 21:29:02][killall:2777] send signo(9) to [cable_dot1x:1908].
[09 21:29:02][killall:2784] send signo(9) to [cable_dot1x:2780].
[09 21:29:12][kill:2932] send signo(15) to [svc_hpd.sh:373].
[09 21:29:12][kill:2932] send signo(15) to [appstart:507].
[09 21:29:12][kill:2932] send signo(15) to [appstart:2125].
[09 21:29:12][kill:2932] send signo(15) to [sh:2927].
[09 21:29:12][kill:2938] send signo(15) to [sh:2933].
[09 01:00:26][killall:1628] send signo(9) to [dot1x.exe:1049].
[09 01:00:35][killall:1641] send signo(9) to [dnsmasq:865].
[22 01:00:21][killall:1359] send signo(9) to [dnsmasq:875].
[22 01:00:21][killall:1392] send signo(9) to [dnsmasq:871].
[23 08:10:14][killall:3381] send signo(9) to [dnsmasq:1602].
[03 01:00:21][killall:1374] send signo(9) to [dnsmasq:867].
[03 21:09:26][killall:2011] send signo(9) to [dnsmasq:1595].
[03 21:32:00][killall:2263] send signo(9) to [dnsmasq:2012].
[03 21:43:14][killall:2514] send signo(9) to [dnsmasq:2264].
[03 21:46:03][killall:2745] send signo(9) to [dnsmasq:2515].
Spezifikationen:
Telefonanlage:
Ich habe hier mal die Diagnosedatei als .zip hochgeladen. Vielleicht findet jemand mehr Hinweise zu diesem Fehler und kann dieses Phänomen bestätigen.
Vielen Dank und schöne Grüße
ich hoffe, der Post ist hier an der richtigen Stelle und der Text wird nicht zu lang.
Ich erkläre zunächst die Struktur, die wir aufgebaut haben:
Wir betreiben ca. 1200 Yealink T57W Telefone in 25 Außenstellen.
Jede Außenstelle verfügt über einen SBC, und die Telefone befinden sich dort im VLAN 160 (unser Telefon-VLAN).
Auch hier in der Zentrale sind etwa 150 Telefone in diesem VLAN.
Die 3CX-Anlage selbst liegt in einer DMZ.
Das Regelwerk zu der VM in der DMZ ist soweit korrekt. SIP-ALG ist auch deaktiviert.
Die Telefone funktionieren grundsätzlich problemlos:
Registrierung, Telefonie und Provisionierung laufen einwandfrei.
Das Problem:
Vereinzelt melden Anwender, dass ihr Telefon plötzlich kein Netzwerk mehr hat.
Fehlermeldung: "No Service" danach "IP-Adresse wird bezogen"
Dieses Phänomen tritt mittlerweile häufiger auf.
Früher, mit älteren Firmware-Versionen, gab es dieses Problem nicht.
Betroffen sind immer wieder andere Telefone – es gibt keine festen Muster oder bestimmte Geräte.
Da wir einen RADIUS-Server (Aruba ClearPass) einsetzen, können wir nachvollziehen, wo das Problem auftritt.
Dort sehen wir, dass einige Telefone sich sporadisch neu anmelden.
Es scheint, als würde sich das Telefon „netzwerkseitig“ zurücksetzen.
Anschließend durchlaufen die Telefone erneut die RADIUS-Authentifizierung und beziehen eine neue IP vom DHCP-Server.
Während dieser Zeit sind sie jedoch nicht erreichbar.
Besonders problematisch wird es, wenn dies während eines Gesprächs passiert!
Beobachtungen:
- Auf dem Switch sehen wir, dass sich die MAC-Adresse erneut auf dem Interface registriert – sonst nichts Auffälliges.
- Das Problem tritt unregelmäßig auf: mal 1-2 Mal, manchmal bis zu 10-20 Mal pro Gerät.
- Auch Telefone, die selten genutzt werden (z. B. in Küche oder Serverraum), sind betroffen.
- Es passiert auch bei Telefonen, die keinen SBC eingetragen haben und direkt zur 3CX verbinden.
- In manchen Wochen tritt das Problem verstärkt auf, in anderen kaum.
[09 21:29:02][killall:2777] send signo(9) to [cable_dot1x:1908].
[09 21:29:02][killall:2784] send signo(9) to [cable_dot1x:2780].
[09 21:29:12][kill:2932] send signo(15) to [svc_hpd.sh:373].
[09 21:29:12][kill:2932] send signo(15) to [appstart:507].
[09 21:29:12][kill:2932] send signo(15) to [appstart:2125].
[09 21:29:12][kill:2932] send signo(15) to [sh:2927].
[09 21:29:12][kill:2938] send signo(15) to [sh:2933].
[09 01:00:26][killall:1628] send signo(9) to [dot1x.exe:1049].
[09 01:00:35][killall:1641] send signo(9) to [dnsmasq:865].
[22 01:00:21][killall:1359] send signo(9) to [dnsmasq:875].
[22 01:00:21][killall:1392] send signo(9) to [dnsmasq:871].
[23 08:10:14][killall:3381] send signo(9) to [dnsmasq:1602].
[03 01:00:21][killall:1374] send signo(9) to [dnsmasq:867].
[03 21:09:26][killall:2011] send signo(9) to [dnsmasq:1595].
[03 21:32:00][killall:2263] send signo(9) to [dnsmasq:2012].
[03 21:43:14][killall:2514] send signo(9) to [dnsmasq:2264].
[03 21:46:03][killall:2745] send signo(9) to [dnsmasq:2515].
Spezifikationen:
Telefonanlage:
- Microsoft Windows Server 2022
- CPU: 16 Kerne
- RAM: 64 GB
- Festplatte: 190 GB
- 3CX Version: 20.0 Update 4 (Build 487 Release)
- Anzahl: ca. 1200 Yealink T57W
- Firmware: 96.86.0.81
- Hardware-Version: 97.0.1.0.0.0.0
Ich habe hier mal die Diagnosedatei als .zip hochgeladen. Vielleicht findet jemand mehr Hinweise zu diesem Fehler und kann dieses Phänomen bestätigen.
Vielen Dank und schöne Grüße
