Ständige SIP-Trunk-Reconnects nach Serverumzug

[vieledinge]

Hallo zusammen,

ich bräuchte mal bisschen Schwarmwissen zu nem Serverumzug. Vielleicht hat ja jemand ne zündende Idee...

Ausgangssituation:

• 3CX, Debian, 18u5 (bitte keine Update-Diskussion, das ist nach dem Umzug geplant)
• Alter Server: HyperV-VM auf Win 2016, ein Netzwerkport
• Neuer Server: HyperV auf Win 2022, geteamter Netzwerkport auf gestackten, redundanten Switchen
• Die VM wurde jeweils exportiert und importiert.
• Einzige Änderung an der Konfiguration: Zwingenderweise die Netzwerkzuweisung.
• Einstellungen für die Zeitsynchronisation sind auch auf beiden Hosts identisch.
• Firewalls auf den Hostsystemen sind identisch. Abschalten bringt auch keine Besserung.
• Das gesamte sonstige Netzwerk ist unverändert. Alle Geräte befinden sich im gleichen VLAN (Standard-VLAN)

Die neue VM startet soweit auch problemlos, allerdings habe ich ständige Ausfälle und Reconnects des SIP-Trunks.

Registration at Easybell has failed. Destination (sip:195.185.214.173:5060;lr) is not reachable, DNS error resolving FQDN, or service is not available.
Registration at Easybell has failed. Destination (sip:195.52.221.142:5060;lr) is not reachable, DNS error resolving FQDN, or service is not available.

Auch der Firewall-Check läuft auf einmal nicht mehr durch. Siehe Screenshot, alle höheren Ports laufen sauber durch. Was ich auch nicht verstehe, an den Firewall-Regeln wurde nichts geändert. Lasse ich während des Firewall-Checks das Livelog auf der Firewall mitlaufen, dann kommen da auch keine relevanten Verbindungen, die geblockt würden.

Teste ich die Netzwerkverbindungen und Namensauflösungen via 3CX-Terminal oder direkt auf dem Host als root aus der Shell, dann sind keinerlei Fehler oder Aussetzer feststellbar.

Irgend jemand ne Idee? Die geteamte Verbindung dürfte ja an sich kein Problem darstellen. Die VM selbst weiß ja davon quasi nichts, die bekommt ja wie bisher nur einen virtuellen Adapter präsentiert.

 

[fxbastler]

Ich weiss nicht, ob das Problem mit dem NIC Teaming zusammenhängt, das verursacht auch sehr gern solche Probleme. Das wäre einfach zu testen: mal eine andere einzelne NIC und einen anderen HV Switch für die Debian 3CX nutzen. Daher verwenden wir es wo es geht nicht mehr. Mehr Leistung auf einer einzelnen NIC und anderweitige Redundanz an Statt NIC Team. Das Deaktivieren der Flußkontrolle reicht meist nicht so wie früher mal.

Aber ja, ab Server 2019 gibt es wesentliche Änderungen im Netzwerkstack und bei den NIC und seit Jahren (Ende 2018) ellenlange Diskussionen deswegen. Fazit: auf dem HV, dem HV Switch (das wird gern vergessen) nach dessen Einrichtung und Windows VM (in deinem Fall nicht von Belang) diverse Einstellungen vornehmen. Wir haben explizit Skripte dafür geschrieben und seitdem gibt es diese Probleme nicht mehr.

Wer ein klein wenig lesen will kann z.B. hier damit anfangen.

 

[vieledinge]

Ach herrje, da ham wer ja wieder mal richtig in die Sch#%&$ gegriffen. Sieht sehr nach dem Problem aus. Ok, muss ich mir nochmal in Ruhe reinziehen und mit dem Kolegen diskutieren.

Temporär wirds dann wohl erst mal mit einer ungeteamten NIC weitergehen, um den Umzug durch zu bekommen.

Danke für die Infos.

 

[fxbastler]

ungeteamten NIC

Mehr GBit pro Leitung, ganz ohne Teaming. Wenn Redundanz, dann diese anderweitig herstellen oder stark gewichten.

Teaming einzurichten, um die Anbindung besser und schneller nutzen zu können, ist grundsätzlich ein Irrtum. Das schafft bei reinen Dateiservern schon Probleme. Bei Telefonie sowieso.

 

[vieledinge]

Es geht weniger um Performanz als um Ausfallsicherheit. Wir haben nen voll redundanten Backbone und möchten da natürlich zwei getrennte Einstiegspunkte auf zwei separate physische Switche (Stack) haben, um im Fehlerfall einfach keinen Single-Point-of-Failure zu haben. Aber ja, wir werden uns da ne andere Lösung überlegen müssen.

 

[fxbastler]

Noch ein Tipp: wenn ihr alle sonstigen Netzwerkanbindungen des Hyper V (außer der 3CX) weiterhin per Team betreiben wollt und die oben angesprochenen (verlinkten) Änderungen durchführt, dann löst vorher unbedingt das Team auf und betreibt alles mal einzeln aktiv. Sonst geht das mit Ansage schief, so richtig. Bis hin zu dem Punkt, dass NIC unlöschbar, unbenutzbar und unkonfigurierbar verbleiben.

 

[vieledinge]

Danke für den Hinweis, werden wir beherzigen.

 

[vieledinge]

Fürs Archiv: Aktuell haben wir keine echte Lösung gefunden. Wir haben nen extra Blech, wieder mit Win2016, aufgesetzt. Dort läuft alles soweit problemlos. Prio haben jetzt erst mal die 3CX-Updates, die Virtualisierungsplattform schauen wir und später nochmal in Ruhe an.

 

[fxbastler]

Trotz eigener einzelner NIC, einzelner Anbindung per Kabel und eigenem Software Switch im HV für die 3CX VM?

 

[vieledinge]

Ja. hat alles nicht geholfen. Vielleicht ist es noch irgend nen beknackter Parameter der Netzwerkkarte oder sowas. Will ich mir nochmal in Ruhe anschauen, wenn bisschen mehr Zeit ist.