SBC Verbindungsabbrüche

KJ_amatrix

Bronze Partner
Basic Certified
Mitglied seit
7. Dezember 2022
Beiträge
4
Hallo,
ich hab folgendes Problem bei einem meiner Kunden.
Hier fliegt die Verbindung zum SBC alle 1-5 Minuten weg.
Intuitiv habe ich alle System geupdatet, Firewallregeln erneut überprüft und sogar den SBC neu aufgesetzt.
Die Problematik bleibt die selbe. => 30-70% Package loss
Sobald ich die PBX Selber bzw. die Dienste der PBX stoppe; besteht das Problem nicht mehr
Starte ich die PBX erneut habe ich wieder 30-70% Package loss
Desweiteren steigend stündlich die "simcalls/gleichz. Anrufe" des SBC's
 

Anhänge

  • Screenshot 2023-04-06 144334.png
    Screenshot 2023-04-06 144334.png
    6,3 KB · Aufrufe: 8
Hallo,

erste Fragen:
  • 3CX Version, z. B. Standard-Jahreslizenz 18.0.6.xxx
  • Server OS, z. B. Debian / Windows Server
  • Wo wird der 3CX Server gehostet? z. B. gehostet bei AWS/Google/Azure/sonst. Cloud Server / eigenes Blech im RZ
  • Wird der 3CX Server virtualisiert betrieben und wenn ja auf welcher Plattform? z. B. nein / ja: KVM, Hyper-V usw.
  • SIP-Trunk-Anbieter, z. B. AT&T SIP-Trunk
  • War der Firewall Checker erfolgreich?: ja/nein
  • Tritt das Problem auch mit anderen SBC am gleichen Standort auf?: ja/nein
  • Tritt das Problem auch mit anderen SBC an anderen Standorten auf?: ja/nein
TEILEN SIE NIE: Lizenzschlüssel, öffentliche IP-Adressen, E-Mail-Adressen, Benutzernamen, Passwörter, FQDNs, Provisionierungs-URLs, etc

Die anderen Fragen kommen später, abhängig von den Antworten auf die obenstehenden Fragen.
 
  • Like
Reaktionen: MarcosV__3CX
3CX Version : Enterprise Jahreslizenz 18.0 (Build 312)
Server OS : SMB Debian 4.19.269-1
Wo wird der 3CX Server gehostet? Cloud Server
Wird der 3CX Server virtualisiert betrieben und wenn ja auf welcher Plattform? Nein
SIP-Trunk-Anbieter: andere
War der Firewall Checker erfolgreich? ja
Tritt das Problem auch mit anderen SBC am gleichen Standort auf? Gibt nur einen
Tritt das Problem auch mit anderen SBC an anderen Standorten auf? Problem tritt bei anderen 3CX Anlagen in selber konstellation nicht auf
 
Server OS : SMB Debian 4.19.269-1
Was genau ist das für ein System? Wenn Debian und 3CX dann Debian 10.
Wo wird der 3CX Server gehostet? Cloud Server
Bitte genauer: wo.
Tritt das Problem auch mit anderen SBC am gleichen Standort auf? Gibt nur einen
Wurde denn testweise ein weiterer (anderer) SBC an diesem Standort in Betrieb genommen? Wenn das Problem so häufig auftritt, wäre es gut zu wissen, ob es auch eine andere Installation (nicht eine neue Installation auf dem gleichen Gerät wie bereits durchgeführt) betrifft.
Tritt das Problem auch mit anderen SBC an anderen Standorten auf? Problem tritt bei anderen 3CX Anlagen in selber konstellation nicht auf
Ich präzisiere die Frage:
Tritt das Problem mit derselben 3CX mit anderen SBC an anderen Standorten auf?
 
Was genau ist das für ein System? Wenn Debian und 3CX dann Debian 10.

Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"

Bitte genauer: wo.
Ein Debian 10 Server bei Hetzner

Wurde denn testweise ein weiterer (anderer) SBC an diesem Standort in Betrieb genommen? Wenn das Problem so häufig auftritt, wäre es gut zu wissen, ob es auch eine andere Installation (nicht eine neue Installation auf dem gleichen Gerät wie bereits durchgeführt) betrifft.
Vor Ort ist der SBC auf einer VM; Die VM läuft auf Hyper-V
In dem Sinne gabs für den SBC bereits eine neue VM. Die Problematik besteht dann weiter.
Unter der selben Schnittstelle bestehen sonst keine Probleme. Lediglich die SBC VM hat hier Probleme.

Tritt das Problem mit derselben 3CX mit anderen SBC an anderen Standorten auf?
An diese 3CX ist nur ein Standort angebunden

Hetzner Cloud 3CX PBX <> Lokaler Server mit Hyper-V VM SBC

Die Konstellation hat soweit auch ein halbes Jahr einwandfrei funktioniert. Nur jetzt auf einmal nicht mehr. Vielen Dank für die schnelle Rückmeldung. Versuche das alles so präzise wie möglich zu beantworten
 
Vor Ort ist der SBC auf einer VM; Die VM läuft auf Hyper-V
  1. Wurde im Hyper V für diese VM der Integrationsdienst Zeitsynchronisierung deaktiviert und im SBC der Dienst ntp installiert?
  2. Wurde im SBC IPv6 komplett deaktiviert (nur so um weitere Fehlerquellen zu reduzieren, das Buch darüber ist lang)?
1x 3CX für einen Standort
Ich würde dennoch irgendwo anders einen SBC neu aufsetzen und an diese 3CX anhängen - nur um zu testen oder der auch solche Probleme aufweist. Wenn dem so ist wird man das evtl. sehr schnell mitbekommen.

Grundsätzlich liest sich das so, als wäre das ein Problem am Standort. Genauer: der Internetverbindung am Standort. Man kann das Problem durch o.g. Maßnahmen und weitere einkreisen.

Die Liste der Möglichkeiten der Fehlersuche ist immer noch sehr lang.
 
  1. Wurde im Hyper V für diese VM der Integrationsdienst Zeitsynchronisierung deaktiviert und im SBC der Dienst ntp installiert?
  2. Wurde im SBC IPv6 komplett deaktiviert (nur so um weitere Fehlerquellen zu reduzieren, das Buch darüber ist lang)?

Die Schritte habe ich eben einmal durchgeführt; allerdings hat vor dem durchführen der Schritte der SBC sich random dazu entschieden wieder normal zu funktionieren. Ich muss das Verhalten morgen einmal erneut überprüfen bzw. ggf. nach den Ostertagen falls es davon abhängig ist.


  1. Wurde die 3CX dort auf dem nackigen Blech mit der von 3CX gelieferten ISO installiert?

    Nachtrag: ... und hat eine eigene IPv4?

Ja und ja! Alles ohne Fehler und auf nacktem Blech mit vorgegebener .iso
Hetzner feste Public IP genauso wie der SBC feste ipv4 außerhalb des DHCP Bereichs
Der Kunde hat ebenfalls eine feste IP
 
Ich wills nicht beschwören aber das Verhalten - vor allem mit den Calls die in die Höhe gehen - ist komisch und würde meine These aus einem anderen Thread bestärken, dass auch On-Premise Anlagen die auf dem Debian ISO basieren und die auf der neusten 7er (312) Version liefen/laufen über die auf ihnen abgelegten .exe Dateien oder anders kompromittiert worden sein könnten.


Und jetzt wo ich so darüber nachdenke, habe ich genau so ein Verhalten eines SBC und einer Anlage auch bei einem Kunden seit ca. 2 Wochen. Immer On/Off. Zwar nicht im 5 Minuten-Takt aber mehrfach am Tag - trotz Firewallfreigaben etc.. Und zufällig ist genau das ein Kunde der auch Fraud Angriffe hatte wie im Thread beschrieben.

Wenn bei dir Netzwerktechnisch alles richtig konfiguriert ist und du explizit auch 5090 an die Hetzner IP freigegeben hast und das immernoch so ist und du wirklich 100% sicher sagen kannst das da nichts blockt, würde ich ggf. mal ein Ticket aufmachen.

Ich will hier keineswegs den Teufel an die Wand malen - ich erkenne nur Parallelen und würde es auch nicht für unmöglich halten das die These in welcher Form und welchem Umfang auch immer ggf. zutreffen könnte, weil mir fällt zumindest aktuell kein logischer Grund ein warum die Anzahl gleichzeitiger Calls ohne euer Zutun einfach so ansteigen sollte.

Sollte es so sein, kannst du den SBC auch zig Mal neu aufsetzen ohne Erfolg. Wenn nämlich auf der Anlage irgendwas läuft worüber du keine Kenntnis hast, das evtl. die Verbindungen regelmäßig unterbricht o.ä. bist du Chancenlos.

Wie gesagt: Alles nur eine Thesen/Vermutung.

@MarcusK_3CX @avraammich_3CX

PS: Du könntest ja mal eine neue On-Premise aufsetzen auf nem anderen Hetzner Host, mit einem neuen Key und dann dort einen SBC anbinden der in eurem Netzwerk steht. Läuft der problemlos muss es ja etwas mit der Anlage sein. Userkonto der zweiten Anlage könntest du dann ja samt Demo-Key wieder löschen am Ende.

Lösche auf jeden Fall die Original Anlage nicht ohne dir vorher ein Image gezogen zu haben. Sollte an meiner These wirklich was dran sein, könnte man daraus wichtige Erkenntnisse ziehen die ggf. allen weiterhelfen.
 
  • Like
Reaktionen: KJ_amatrix

Statistik des Forums

Themen
44.414
Beiträge
232.719
Mitglieder
78.330
Neuestes Mitglied
uvitas