20 Mbit / s WAN über den IPSec-Tunnel auf 10 Mbit / s begrenzt

Wir haben kürzlich einen Remote-Standort von einer 10/10-Mbit / s-Glasfaser auf eine 20/20-Mbit / s-Glasfaserverbindung aktualisiert (es handelt sich um Glasfaser zum Keller, dann VDSL vom Keller zum Büro, ungefähr 30 Meter). Zwischen dieser Site und einer zentralen Site befinden sich regelmäßig große (Multi-Gig-) Dateikopien. Die Theorie besagte daher, dass eine Erhöhung des Links auf 20/20 die Übertragungszeiten ungefähr halbieren sollte.

Für Übertragungen zum Kopieren von Dateien (z. B. robocopyzum Kopieren von Dateien in beide Richtungen oder zur Replikation von Veeam Backup and Recovery) sind sie auf 10 Mbit / s begrenzt.

Vor dem Upgrade:

Nach dem Upgrade ( robocopy):

Fast identisch (ignorieren Sie den Unterschied in der Zeitdauer der Übertragung).

Die Übertragungen erfolgen über einen IPSec-Tunnel zwischen einem Cisco ASA5520 und einem Mikrotik RB2011UiAS-RM .

Erste Gedanken:

• QoS - nein. Es gibt QoS-Regeln, aber keine, die diesen Ablauf beeinflussen sollten. Ich habe alle Regeln für ein paar Minuten deaktiviert, um sie trotzdem zu überprüfen, und keine Änderung
• Software-definierte Grenzen. Der größte Teil dieses Datenverkehrs wird von Veeam Backup and Recovery außerhalb des Standorts versendet, es sind jedoch keine Einschränkungen definiert. Außerdem habe ich gerade eine Straße gemacht robocopyund genau die gleichen Statistiken gesehen.
• Hardware nicht fähig. Nun, die veröffentlichten Leistungsdaten eines 5520 sind 225 Mbit / s 3DES-Daten, und die Mikrotik veröffentlicht keine Zahlen, aber es wären weit über 10 Mbit / s. Die Mikrotik hat bei diesen Übertragungstests eine CPU-Auslastung von etwa 25% bis 33%. (Eine HTTP-Übertragung über den IPSec-Tunnel erreicht fast 20 Mbit / s.)
• Latenz kombiniert mit TCP-Fenstergröße? Nun, es ist eine Latenz von 15 ms zwischen den Standorten, sodass selbst eine Fenstergröße 32*0.015von 32 KB im schlimmsten Fall maximal 2,1 MB / s beträgt. Darüber hinaus summieren sich mehrere gleichzeitige Übertragungen immer noch auf nur 10 Mbit / s, was diese Theorie nicht unterstützt
• Vielleicht sind Quelle und Ziel beide Scheiße? Nun, die Quelle kann anhaltende sequentielle Lesevorgänge mit 1,6 GB / s ausführen, das ist es also nicht. Das Ziel kann anhaltende sequentielle Schreibvorgänge mit 200 MB / s ausführen, das ist es also auch nicht.

Dies ist eine sehr merkwürdige Situation. Ich habe noch nie etwas gesehen, das sich auf diese Weise manifestiert.

Wo kann ich sonst noch suchen?

Bei weiteren Untersuchungen bin ich zuversichtlich, auf den IPSec-Tunnel als Problem hinzuweisen. Ich habe ein erfundenes Beispiel erstellt und einige Tests direkt zwischen zwei öffentlichen IP-Adressen auf den Sites durchgeführt und dann genau denselben Test unter Verwendung der internen IP-Adressen durchgeführt. Ich konnte 20 Mbit / s über das unverschlüsselte Internet und nur 10 Mbit / s auf der IPSec replizieren Seite.

Vorherige Version hatte einen roten Hering über HTTP. Vergessen Sie dies, dies war ein fehlerhafter Testmechanismus.

Gemäß dem Vorschlag von Xeon und dem Echo meines ISP, als ich ihn um Unterstützung bat, habe ich eine Mangle-Regel eingerichtet, um das MSS für die IPSec-Daten auf 1422 zu setzen - basierend auf dieser Berechnung :

 1422   +  20 + 4 +  4 +   16  +   0     +      1    +     1     +   12
PAYLOAD  IPSEC SPI ESP  ESP-AES ESP (Pad)  Pad Length Next Header ESP-SHA

Passend in die 1480 MTU des ISP. Aber leider hat dies keinen wirksamen Unterschied gemacht.

Nach dem Vergleich von Wireshark-Erfassungen handelt die TCP-Sitzung jetzt an beiden Enden eine MSS von 1380 aus (nachdem einige Dinge optimiert und ein Puffer hinzugefügt wurden, falls meine Mathematik nicht funktioniert. Hinweis: Dies ist wahrscheinlich der Fall). 1380 ist ohnehin auch das Standard-MSS der ASA, daher hat sie dies möglicherweise ohnehin die ganze Zeit ausgehandelt.

Ich sehe einige seltsame Daten im Tool in der Mikrotik , mit denen ich den Verkehr gemessen habe. Es könnte nichts sein. Ich habe dies vorher nicht bemerkt, da ich eine gefilterte Abfrage verwendet habe, und ich habe dies erst gesehen, als ich den Filter entfernt habe.

Obwohl die CPU das dritte war, was ich überprüft habe, schrieb ich Folgendes:

Die Mikrotik hat bei diesen Übertragungstests eine CPU-Auslastung von etwa 25% bis 33%

Was durch das CPU-Diagramm bestätigt wird

Ich habe durch externe Ressourcen (z. B. eine Reihe anderer Support-Foren und Blogs ) bestätigt, dass die meisten Mikrotik-Router nicht mehr als 11 Mbit / s IPSec-Verkehr mit 3DES- oder AES-Verschlüsselung übertragen können, es sei denn, Sie erhalten ein Modell mit Hardware-Verschlüsselungs-Offloading .

Es sieht also so aus, als wäre dies nur eine Hardwarebeschränkung. Ich hätte es viel früher fangen sollen, aber aus irgendeinem Grund zeigte mir die Mikrotik nicht an, dass es CPU-gebunden war.

Ich gehe einkaufen.

Ich kann bestätigen, dass der Schuldige die CPU ist. Hier habe ich einen Mikrotik RB750GL verglichen und 12 Mbit / s mit AES-128-Verkehr gemessen (und nur 6,0 Mbit / s mit 3DES).

Ihr Ergebnis scheint perfekt mit dem übereinzustimmen, was ich aufgezeichnet habe.