GELÖST: Site2Site Verbindung einseitig extrem langsam

[pixl]

Hallo!

Meine Kollegen in der Zweigstelle beschweren sich über die langsame Verbindung zum Hauptwerk rüber.
Als ich die Verbindung geprüft hatte, kam folgendes raus:

Anbindung
Hauptwerk: 100Mbit down; 40Mbit up. (liegen an, laut Speedtest)
Zweigstelle: 100Mbit down; 40Mbit up. (liegen an, laut Speedtest)

Hardware:
Hauptwerk: LC 1790VA-4G (10.80.0233) -latest
Zweigstelle: LC 1783VA-4G (10.50.1301) -latest

Site2Site Verbindung:
Dauerhafte Verbindung zwischen den zwei Routern (hält stabil).
IKEv2 / UDP (AES_CBC 256Bit); HMAC-SHA-256 (256Bit); Kompression: keine; SSL Kapselung: keine

Nun ist es so, dass die volle Leistung (40Mbit) einseitig funktioniert.
Über iPerf habe ich gemessen:
Ist die Zweigstelle der Server, bekomme ich volle Leistung (~40Mbit)
Ist das Hauptwerk der Server, kommen ca. ~1Mbit durch (SMB Geschwindigkeit hängt bei so ziemlich genau 355kb/s.)

Will die Zweigstelle etwas zum Hauptwerk schubsen (SMB), kommen die genannten 1Mbit zu tragen (zu Beginn eiert der Upload bei 2-3MB/s, fällt dann massiv ab und hält sich bei 355kb/s).

Holt das Hauptwerk von der Zweigstelle (SMB), erhalte ich vollen Speed.
CPU Last nicht höher als 15-20%.

Firmware sind aktuell, Kabel in Ordnung. SMB Signing und verschlüsselung zu testzwecken deaktiviert - keine Änderung.
Firewall (Router) deaktiviert - keine Änderung.
Alle Geräte im Netz neu gestartet.
bzgl. MTU, bin ich unsicher (alles auf default)

Mir gehen die Ideen aus und hoffe, dass ich hier vielleicht einen Hinweis finden könnte, der uns weiterhilft.

Mir leuchtet das einfach nicht ein, warum nur "oneway" vernünftige Geschwindigkeiten bringt.

Habt Ihr eine Idee, was ich noch prüfen kann?

Falls ich was vergessen habe, oder Ihr weitere Infos benötigt, bitte einen kurzen Hinweis, Infos werden asap nachgetragen.

Danke und viele Grüße,
pixl

[pixl]

Hallo,

ich habe auf beiden Seiten die MTU angepasst (LANconfig: VPN -> IKeV2 -> Erweiterte Einstellungen -> MTU auf 1379 (bis dahin wird nicht fragmentiert)).
VPN anschließend getrennt und neu verbunden.

Geändert hat sich eher nichts

iPerf: Hauptwerk als Server; Nebenwerk als Client:

iPerf_Hauptwerk_als_Server.PNG

iPerf: Nebenwerk als Server; Hauptwerk als Client:

iPerf_Nebenwerk_als_server.PNG

Habt Ihr noch eine Idee, wo ich schauen könnte?

Unter Kommunikation -> Protokolle -> MTU-Liste habe ich den MTU auch mal gesetzt für beide Seiten -> keine Änderung

Danke + guten Start in den Tag,
viele Grüße
pixl

[Dr.Einstein]

Ist an einen der Standorte der Voice Call Manager im Einsatz?

[pixl]

Ist an einen der Standorte der Voice Call Manager im Einsatz?

ja! Im Nebenwerk. Was hat es damit auf sich?

vcm.png

192.168.20.22 ist der Telefonserver im Hauptwerk. (Telefonie klappt)
Ps.: eben den Schreibfehler entdeckt[GATWAY] -> behoben

Nachtrag: tracert und DNS Auflösungen laufen prima.

Liebe Grüße

[Dr.Einstein]

Kontrollier mal unter Voice Call Manager / Erweitert ob dort eine PMTU Reduzierung hinterlegt ist. Wenn ja, beide Einträge deaktivieren und die WAN Verbindung trennen.

[pixl]

Kontrollier mal unter Voice Call Manager / Erweitert ob dort eine PMTU Reduzierung hinterlegt ist. Wenn ja, beide Einträge deaktivieren und die WAN Verbindung trennen.

Oh, das klingt vielversprechend!

Habe ich, sieht auch aus, als würde da was reduziert werden (576 byte?), aber welche 2 Einträge soll ich deaktivieren?

vcm2.png

Liebe Grüße

Nachtrag: okay, scheint doch nicht reduziert zu werden, ABER: wir haben QoS für VoIP gesetzt, kann dies ein Thema sein/werden?

qos.png

[Dr.Einstein]

VCM ist es nicht, ausgehend und eingehend ist "keine" gesetzt.

Nach QoS habe ich nicht gefragt, weil du meintest, du hast die Firewall deaktiviert. Damit wäre auch QoS deaktiviert. Ich würde aber sagen ja, es liegt daran. Du hast keine Richtungseinschränkung, sodass der Lancom auch ankommend versucht, zu droppen.

[pixl]

VCM ist es nicht, ausgehend und eingehend ist "keine" gesetzt.

Nach QoS habe ich nicht gefragt, weil du meintest, du hast die Firewall deaktiviert. Damit wäre auch QoS deaktiviert. Ich würde aber sagen ja, es liegt daran. Du hast keine Richtungseinschränkung, sodass der Lancom auch ankommend versucht, zu droppen.

Es scheint tatsächlich, in die Richtung zu gehen. Die FW hatte ich aus aber damit veränderte sich (scheinbar?) nichts.
Habe die Regeln mal deaktiviert und es scheint schneller zu sein (zumindest schonmal 20mbit/s).

Wie müsste ich das QoS korrekt setzen? (habe telefonie + QoS nicht eingerichtet).

Danke für deine Mühen!

Nachtrag: QoS Regel wieder eingeschalten -> keine Veränderung der ~20Mbit/s

Connecting to host 192.168.50.66, port 5201
[ 4] local 192.168.4.187 port 55782 connected to 192.168.50.66 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 1.50 MBytes 12.6 Mbits/sec
[ 4] 1.00-2.00 sec 2.00 MBytes 16.8 Mbits/sec
[ 4] 2.00-3.00 sec 2.00 MBytes 16.8 Mbits/sec
[ 4] 3.00-4.00 sec 1.75 MBytes 14.7 Mbits/sec
[ 4] 4.00-5.00 sec 2.00 MBytes 16.8 Mbits/sec
[ 4] 5.00-6.00 sec 1.88 MBytes 15.7 Mbits/sec
[ 4] 6.00-7.00 sec 1.88 MBytes 15.7 Mbits/sec
[ 4] 7.00-8.00 sec 1.88 MBytes 15.7 Mbits/sec
[ 4] 8.00-9.00 sec 1.75 MBytes 14.7 Mbits/sec
[ 4] 9.00-10.00 sec 1.88 MBytes 15.7 Mbits/sec

[Dr.Einstein]

Auf beiden Seiten alle QoS Regeln deaktivieren und danach WAN trennen und erneut testen. Erst wenn du auf 40 Mbit/s kommst, hast du die Ursache identifiziert.

[pixl]

Auf beiden Seiten alle QoS Regeln deaktivieren und danach WAN trennen und erneut testen. Erst wenn du auf 40 Mbit/s kommst, hast du die Ursache identifiziert.

Code: Alles auswählen

WAN trennen

habe ich tatsächlich nie gemacht (schwierig im Produktivumfeld).
Danke! Ich denke echt, dass es das war. Die 20 Mbit/s passen auch (Schnee auf Antenne).

Ich würde sagen, dies ist gelöst! Ich wäre auch nie auf den VCM gekommen ... (Ich beobachte aber weiter)

Vielen Dank Dr. Einstein

Liebe Grüße

[dMatschek]

Ich würde aber sagen ja, es liegt daran. Du hast keine Richtungseinschränkung, sodass der Lancom auch ankommend versucht, zu droppen.

Zum weiteren Verständniss: Wie kann denn solche eine QoS Regel mit wenigen kb/s eine derart signifikante Auswirkung (20 MBit weniger) auf den restlichen Datenstrom haben?

VG,
Matschek

[Dr.Einstein]

Andere Hersteller mit Brückensymbol können mit ankommendem QoS wesentlich besser umgehen als Lancom. Muss man einfach so hinnehmen, dafür kosten die Plastikkisten aber meist nur 1/10 von denen.

Meine Empfehlung: Baue QoS Regeln nur für den Upload. Und vergiss die SIP QoS Regel, wozu willst du bei einem 40 Mbit/s Anschluss Übertragungsrate reservieren, für vllt. 10 SIP Pakete je 5 Minuten. Völliger Quatsch. Wenn du SIP auf TCP umstellst, hast du davon wesentlich mehr als die QoS Regel.

Für die Sprache selbst würde ich eine Regel schreiben nach dem Muster:
- Quelle (Port) / Ziele (Port) beliebig
- Aktion ACCEPT
- QoS 120 kbit/s pro Station, abgehend, VPN, DSCP: EF

Wenn du allerdings eine TK-Anlage nutzt mit Analogendgeräte etc. vielleicht von 120 kbit/s Station auf xx kbit/s global umstellen. Musst du selbst gucken, wie viele Gespräche zeitgleich erfolgen.