12
Download von Server erhöht RTT und Package Loss
Hallo zusammen,
ich habe seit einiger Zeit die Situation, dass in unserer Firma von einem spezifischen Downloadserver in den USA nur sehr langsame Downloadraten möglich sind. Ebenfalls seit einiger Zeit, habe ich auf einer Glasfaserleitung sporadisch Paketausfälle wofür ich bisher keine Erklärung hatte.
Nun habe ich mich damit mal intensiv beschäftigt und habe festgestellt, dass wenn per Glasfaser (1000MBit) auf diesen spezifischen Server zugegriffen wird, der RTT am PfSense Gateway teilweise bis hoch zu 200ms geht und selten mal der Package Loss auf bis zu 30%, sich aber meist um 2-10% bewegt.
Der Download ist ermüdend langsam mit vielleicht 2-4 Mbit.
Normalerweise sind es 0,0% und ca. 1,5ms RTT. Downloadraten von 500MBit sind bei unseren Verbindungen üblich.
Route ich auf die Backup Leitung (Kabel 100 MBit down). Geht dort der RTT hoch auf ca. 120ms aber ohne Package Loss und mit Linespeed 100MBit down bei diesem Server im Download.
In beiden Fällen sitzt vor der PfSense als "Anbieterouter" eine Fritzbox. Der Server läuft via Amazon S3.
Kann jemand dieses Verhalten irgendwie einordnen?
lg
Theo
ich habe seit einiger Zeit die Situation, dass in unserer Firma von einem spezifischen Downloadserver in den USA nur sehr langsame Downloadraten möglich sind. Ebenfalls seit einiger Zeit, habe ich auf einer Glasfaserleitung sporadisch Paketausfälle wofür ich bisher keine Erklärung hatte.
Nun habe ich mich damit mal intensiv beschäftigt und habe festgestellt, dass wenn per Glasfaser (1000MBit) auf diesen spezifischen Server zugegriffen wird, der RTT am PfSense Gateway teilweise bis hoch zu 200ms geht und selten mal der Package Loss auf bis zu 30%, sich aber meist um 2-10% bewegt.
Der Download ist ermüdend langsam mit vielleicht 2-4 Mbit.
Normalerweise sind es 0,0% und ca. 1,5ms RTT. Downloadraten von 500MBit sind bei unseren Verbindungen üblich.
Route ich auf die Backup Leitung (Kabel 100 MBit down). Geht dort der RTT hoch auf ca. 120ms aber ohne Package Loss und mit Linespeed 100MBit down bei diesem Server im Download.
In beiden Fällen sitzt vor der PfSense als "Anbieterouter" eine Fritzbox. Der Server läuft via Amazon S3.
Kann jemand dieses Verhalten irgendwie einordnen?
lg
Theo
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1596361814
Url: https://administrator.de/contentid/1596361814
Printed on: April 25, 2024 at 17:04 o'clock
12 Comments
Latest comment
Wenn bei einem Server die RTT so hoch ist müsste das TCP-Window bzw. die TCP-Buffers des Servers entsprechend hoch sein damit damit die Downloadrate auch noch entsprechend hoch ist, diese sind aber vom Server begrenzt da für jeden genügend Ressourcen bereitstehen müssen.
https://www.switch.ch/network/tools/tcp_throughput/
Wenn dieser Server bzw. die komplette Strecke zu diesem also entsprechend ausgelastet ist dann liefert diese auch nur das was mit dieser RTT und dessen TCP-Window/Buffers möglich ist.
https://www.switch.ch/network/tools/tcp_throughput/
Wenn dieser Server bzw. die komplette Strecke zu diesem also entsprechend ausgelastet ist dann liefert diese auch nur das was mit dieser RTT und dessen TCP-Window/Buffers möglich ist.
Hallo,
das verrückte ist aber, dass es auf der Backupleitung zwar auch mit einem hohen RTT, aber gleichzeitig mit 100MBit Download ohne Probleme läuft.
Im Direkten Anschluss mit doppeltem quercheck getestet. Es liegt definitiv nicht an der reinen Serverauslastung.
das verrückte ist aber, dass es auf der Backupleitung zwar auch mit einem hohen RTT, aber gleichzeitig mit 100MBit Download ohne Probleme läuft.
Im Direkten Anschluss mit doppeltem quercheck getestet. Es liegt definitiv nicht an der reinen Serverauslastung.
Dann hat dein Backup-ISP wohl das bessere Routing zu dem spezifischen Server. Mach halt mal ein traceroute mit beiden und vergleiche.
das ist jetzt schräg. Egal welche Leitung ich Outbound wähle, die erste externe IP beim tracert ist die selbe 1&1 Versatel IP. Das ist unser Glasfaseranbieter. WieistmeineIp.de gibt allerdings die jeweils Korrekte Outbound IP an.
Gleicher Effekt bei tracert in Windows und direkt auf der PfSense mit Wahl des Source Interface. Egal ob UDP oder ICMP. Die Gatewayregel ist TCP/UDP.
Gleicher Effekt bei tracert in Windows und direkt auf der PfSense mit Wahl des Source Interface. Egal ob UDP oder ICMP. Die Gatewayregel ist TCP/UDP.
Zitat von @theoberlin:
das ist jetzt schräg. Egal welche Leitung ich Outbound wähle, die erste externe IP beim tracert ist die selbe 1&1 Versatel IP.
das ist jetzt schräg. Egal welche Leitung ich Outbound wähle, die erste externe IP beim tracert ist die selbe 1&1 Versatel IP.
Das ist ja wayne, wie sieht der gesamte Trace von beiden Leitungen aus?
Wahrscheinlich hast du 7-8 Hops ohne Zeitüberschreitung auf der Backup-Line und 11-13 Hops mit Zeitüberschreitung auf der Main-Line.
Dann hat dein Glas-Provider das BGP-Routing entweder verkackt, oder nicht dafür gezahlt.
VG
Wenn die GW Regel nur für TCP/UDP gilt geht ICMP immer über den selben Anbieter. Windows macht traceroute default über ICMP.
Dito von meiner Seite.
Dito von meiner Seite.
Das gibts doch nicht..egal was ich beim trace in der PfSense als Source Interface einstelle, es ist immer das Glasfaser Gateway als erster Hop.
Dabei ist unwichtig ob UDP oder ICMP. Ich hänge mich mal eben mit einem Laptop direkt in die Gateways.
lg
Theo
Dabei ist unwichtig ob UDP oder ICMP. Ich hänge mich mal eben mit einem Laptop direkt in die Gateways.
lg
Theo
Dreh mal dein Kopf nach links, dann nach rechts und wenn möglich, schau nach hinten. Du wirst feststellen, da wird keiner aus dem Forum sein, der dir über die Schulter auf den Bildschirm glotzt.
Somit kann dir keiner sagen, was du für Murks in deiner Sense eingerichtet hast.
Es sei denn, du zeigst deine Konfiguration.
Somit kann dir keiner sagen, was du für Murks in deiner Sense eingerichtet hast.
Es sei denn, du zeigst deine Konfiguration.
Edit als neuer Kommentar
So jetzt habe ich zumindest saubere traces:
Glasfaser:
Kabel:
Nach dem 9. Hop ist Schluss. Macht insofern keinen Sinn als das die Glasfaser die problematische Leitung ist und die Kabel Leitung die schnelle, aber beim trace wesentlich schlechtere Werte hat bzw. vor dem Ende eine Zeitüberschreitung ausgibt.
Allerdings sind beide letzten Hops Amazon IPs.
@ Caveman
Warum die Traces der PfSense nicht aus dem korrekten Source Interface rausgehen schaue ich mir später nochmal an. Definitiv wird das Outbound Gateway für den Client aber korrekt umgestellt. Der trace über ICMP bei Windows erklärt auf jeden fall warum das da nicht gegriffen hat.
So jetzt habe ich zumindest saubere traces:
Glasfaser:
1 fritz.box (10.0.1.4) 0.736 ms 0.402 ms 0.383 ms
2 62.214.37.246 (62.214.37.246) 3.927 ms 3.955 ms 3.415 ms
3 62.214.37.245 (62.214.37.245) 2.639 ms 4.169 ms 2.580 ms
4 62.214.39.214 (62.214.39.214) 3.008 ms
62.214.39.212 (62.214.39.212) 2.918 ms 4.596 ms
5 99.82.183.192 (99.82.183.192) 7.518 ms 3.830 ms 3.727 ms
6 52.93.49.79 (52.93.49.79) 3.424 ms 3.349 ms
52.93.49.73 (52.93.49.73) 8.865 ms
7 *Kabel:
1 10.0.2.4 (10.0.2.4) 0.642 ms 0.511 ms 1.054 ms
2 ip5b4031fe.dynamic.kabel-deutschland.de (91.64.49.254) 11.104 ms 14.717 ms 14.250 ms
3 83-169-180-46-isp.superkabel.de (83.169.180.46) 10.580 ms 14.655 ms 8.868 ms
4 ip53a99c95.static.kabel-deutschland.de (83.169.156.149) 12.730 ms 7.909 ms 19.943 ms
5 145.254.3.196 (145.254.3.196) 20.011 ms 9.451 ms 9.909 ms
6 145.254.2.215 (145.254.2.215) 14.929 ms 21.014 ms 18.355 ms
7 145.254.2.215 (145.254.2.215) 15.018 ms 14.555 ms 20.225 ms
8 99.83.69.242 (99.83.69.242) 21.433 ms 22.535 ms 15.788 ms
9 150.222.86.48 (150.222.86.48) 17.076 ms
150.222.86.64 (150.222.86.64) 15.458 ms
150.222.86.32 (150.222.86.32) 39.507 ms
10 * * *
11 * * *Nach dem 9. Hop ist Schluss. Macht insofern keinen Sinn als das die Glasfaser die problematische Leitung ist und die Kabel Leitung die schnelle, aber beim trace wesentlich schlechtere Werte hat bzw. vor dem Ende eine Zeitüberschreitung ausgibt.
Allerdings sind beide letzten Hops Amazon IPs.
@ Caveman
Warum die Traces der PfSense nicht aus dem korrekten Source Interface rausgehen schaue ich mir später nochmal an. Definitiv wird das Outbound Gateway für den Client aber korrekt umgestellt. Der trace über ICMP bei Windows erklärt auf jeden fall warum das da nicht gegriffen hat.
so jetzt nochmal in Sauber mit Gatewaywechsel inkl. ICMP in der Sense und trace direkt vom Client:
Glasfaser:
Kabel:
Durchgelaufene traces ohne Timeout. Aber bei der (real) performanteren Leitung mehr Hops und schlechtere Werte.
Die Kabel Leitung hat am ende aber nochmal nen weiteren Hop zu einer Amazon IP.
Glasfaser:
1 <1 ms <1 ms <1 ms 10.0.1.4
2 6 ms 5 ms 2 ms 62.214.37.246
3 2 ms 1 ms 1 ms 62.214.37.245
4 2 ms 2 ms 1 ms 62.214.39.212
5 2 ms 1 ms 1 ms 99.82.183.194
6 3 ms 2 ms 2 ms 52.93.49.87
7 2 ms 1 ms 1 ms afe65da3736f118fa.awsglobalaccelerator.com [76.223.25.251]Kabel:
1 <1 ms <1 ms <1 ms 10.0.2.4
2 14 ms 10 ms 17 ms ip5b4031fe.dynamic.kabel-deutschland.de [91.64.49.254]
3 11 ms 12 ms 15 ms ip53a9b42e.static.kabel-deutschland.de [83.169.180.46]
4 9 ms 10 ms 13 ms ip53a99c95.static.kabel-deutschland.de [83.169.156.149]
5 16 ms 16 ms 13 ms 145.254.3.196
6 35 ms 30 ms 38 ms 145.254.2.215
7 61 ms 48 ms 93 ms 145.254.2.215
8 15 ms 17 ms 18 ms 99.83.69.242
9 17 ms 18 ms 18 ms 150.222.86.144
10 18 ms 14 ms 22 ms afe65da3736f118fa.awsglobalaccelerator.com [76.223.25.251]Durchgelaufene traces ohne Timeout. Aber bei der (real) performanteren Leitung mehr Hops und schlechtere Werte.
Die Kabel Leitung hat am ende aber nochmal nen weiteren Hop zu einer Amazon IP.
Niemand eine Idee?
Bei den Amazon-Services wundert mich gar nichts mehr 
.
.