htp: Peeringprobleme zu Hetzner?

ConiKost

Hat jemand eine Einschätzung, ob das Peeringprobleme sind? Ich habe einen GF-Anschluss von htp und eine Dedi-Serverkiste bei Hetzner. Seit einiger Zeit (einen genauen Zeitrahmen kann ich nicht sagen) fällt mir auf, dass ich massive Uploadprobleme (getestet https, ftp und scp) habe. Während Download vom der Hetznerkiste nahezu vollen Gigaspeed bringt, läuft der Upload mit maximal 150-200kb/s. Egal zu welcher Uhrzeit. Sei es 3 Uhr nachts oder 14 Uhr Nachmittag oder 10 Uhr Vormittag.

Sobald ich zur erwähnten Hetznerkiste einen Wireguard-Tunnel (Wireguard ist direkt auf der Hetznerkiste installiert) direkt aufbaue (Alles wird dann darüber geroutet), habe ich allerdings vollen Uploadspeed. Wenn ich trenne, bricht die Geschwindigkeit sofort ein. Würde das aber nicht eher gegen ein Peeringproblem sprechen, da doch die Verbindung per Wireguard effektiv den selben Weg zum Server geht wie ohne?

Die regulären Testseiten für Geschwindigkeitstests wie speedtest.net oder Breitbandmessung liefern volle Geschwindigkeit.

MTR sieht aus meiner Sicht unauffällig aus?

=== Client -> Hetzner (IPv4) ===
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| cerberus.bsg75.lan - 0 | 9 | 9 | 0 | 0 | 0 | 0 |
| a81-14-248-224.net-htp.de - 0 | 9 | 9 | 1 | 1 | 6 | 6 |
| a81-14-249-144.net-htp.de - 0 | 9 | 9 | 1 | 10 | 47 | 25 |
| Gi-6-1-0-1308.HRZ-R-P-00.net-htp.de - 0 | 9 | 9 | 2 | 11 | 56 | 2 |
| Gi-1-1-0-1160.HTZ-R-P-00.net-htp.de - 0 | 9 | 9 | 1 | 1 | 4 | 1 |
| decix-gw.hetzner.com - 0 | 9 | 9 | 7 | 7 | 7 | 7 |
| core23.fsn1.hetzner.com - 0 | 9 | 9 | 11 | 11 | 12 | 12 |
| ex9k2.dc3.fsn1.hetzner.com - 0 | 9 | 9 | 11 | 11 | 11 | 11 |
| xxxxxxxx.de - 0 | 9 | 9 | 12 | 12 | 12 | 12 |
|________________________________________________|______|______|______|______|______|______|

=== Hetzner -> Client (IPv4) ===

Start: 2024-11-13T11:05:57+0100
HOST: xxxxxxxxx Loss% Snt Last Avg Best Wrst StDev
1.|-- static.17.209.4.46.clients.your-server.de (46.4.209.17) 0.0% 10 0.2 2.7 0.2 13.9 5.2
2.|-- core24.fsn1.hetzner.com (213.239.229.245) 0.0% 10 0.3 0.8 0.3 3.1 1.0
3.|-- core4.fra.hetzner.com (213.239.224.90) 0.0% 10 4.9 4.9 4.8 5.0 0.0
4.|-- ipv4.de-cix.fra.de.as13045.htp.net (80.81.195.102) 0.0% 10 10.6 10.7 10.6 10.8 0.1
5.|-- a81-14-249-160.net-htp.de (81.14.249.160) 0.0% 10 17.6 20.9 11.3 51.2 14.7
6.|-- a81-14-249-8.net-htp.de (81.14.249.8) 0.0% 10 11.8 13.8 11.1 21.1 3.8
7.|-- a81-14-249-145.net-htp.de (81.14.249.145) 0.0% 10 26.7 13.7 11.2 26.7 5.2
8.|-- axx-xxx-xx-xxx.net-htp.de (xx.xxx.xx.xxx) 0.0% 10 11.7 11.7 11.7 11.8 0.0

=== Client -> Hetzner (IPv6) ===

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| xxxx:xxx:xxxx:xxxx:xxx:xxx:xx:1 - 0 | 14 | 14 | 0 | 0 | 1 | 0 |
| 2a02:560:1:1::26 - 10 | 10 | 9 | 0 | 1 | 1 | 1 |
| 2a02:560:1:2a::1 - 0 | 14 | 14 | 1 | 3 | 16 | 2 |
| 2a02:560:1:9::2 - 0 | 14 | 14 | 1 | 2 | 7 | 4 |
| 2a02:560:1:e1::2 - 0 | 14 | 14 | 1 | 1 | 4 | 3 |
| decix2-gw.hetzner.com - 0 | 14 | 14 | 7 | 7 | 7 | 7 |
| core24.fsn1.hetzner.com - 0 | 14 | 14 | 11 | 11 | 11 | 11 |
| ex9k2.dc3.fsn1.hetzner.com - 0 | 13 | 13 | 11 | 11 | 11 | 11 |
| xxxxxxxx.de - 0 | 13 | 13 | 11 | 11 | 11 | 11 |
|________________________________________________|______|______|______|______|______|______|

=== Hetzner -> Client (IPv6) ===

Start: 2024-11-13T11:09:07+0100
HOST: xxxxxxxxx Loss% Snt Last Avg Best Wrst StDev
1.|-- 2a01:4f8::a:12:b 0.0% 10 0.2 0.3 0.2 0.4 0.0
2.|-- core22.fsn1.hetzner.com (2a01:4f8:0:3::6a5) 0.0% 10 0.4 1.4 0.3 9.9 3.0
3.|-- core0.fra.hetzner.com (2a01:4f8:0:3::4e2) 0.0% 10 4.9 4.9 4.9 5.0 0.1
4.|-- ipv6.de-cix.fra.de.as13045.htp.net (2001:7f8::32f5:0:1) 0.0% 10 10.6 13.8 10.5 27.1 6.9
5.|-- 2a02:560:1:e2::1 0.0% 10 11.4 11.9 10.8 15.1 1.4
6.|-- 2a02:560:1:c::1 0.0% 10 21.3 12.9 11.0 21.3 3.6
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- xxxx:xxx:xxxx:xxxx:xx:xxx:xx:xxx 0.0% 10 11.5 11.5 11.4 11.5 0.0

pufferueberlauf

Kannst Du die MTR tests noch zweimal wiederholen, aber ueber laengere Zeit gemessen (z.B. 100 Sekunden)?

A) mit Last in Client -> Hetzner Richtung

B) mit Last in Hetzner -> Client Richtung

ConiKost

Mit Last meinst du, wenn ich parallel so langsam hochladen? Dann hier. Ich sehe aber Null Unterschied.. Upload dümpelt mit ca. 85kb/s hoch. Verbindung via IPv6. IPv4 verhält sich identisch. Selbst im Falle von Download sehe ich Null Unterschied zu den unteren neuen MTR-Ausgaben.

Aber wenn es ein Peeringproblem wäre, dann dürfte doch ein direkter Wireguard-Tunnel das Problem eigentlich nicht umgehen? Wäre das jetzt ein anderer Server, wo ich mich hinverbinde, dann würde ich das in Richtung Peering deuten. Aber so?

Client -> Server

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| xxxx:xxx:xxxx:xxxx:xxx:xxx:xx:1 - 0 | 111 | 111 | 0 | 0 | 0 | 0 |
| 2a02:560:1:1::26 - 1 | 107 | 106 | 0 | 2 | 31 | 2 |
| 2a02:560:1:2a::1 - 0 | 111 | 111 | 1 | 5 | 65 | 6 |
| 2a02:560:1:9::2 - 0 | 111 | 111 | 1 | 6 | 56 | 2 |
| 2a02:560:1:e1::2 - 0 | 111 | 111 | 1 | 1 | 17 | 1 |
| decix-gw.hetzner.com - 0 | 111 | 111 | 7 | 7 | 7 | 7 |
| core24.fsn1.hetzner.com - 0 | 111 | 111 | 11 | 11 | 12 | 11 |
| ex9k2.dc3.fsn1.hetzner.com - 0 | 111 | 111 | 11 | 11 | 26 | 11 |
| xxxxxxxx.de - 0 | 111 | 111 | 11 | 11 | 12 | 11 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)

Server -> Client

Start: 2024-11-13T23:06:19+0100
HOST: xxxxxxxx Loss% Snt Last Avg Best Wrst StDev
1.|-- 2a01:4f8::a:12:b 0.0% 110 0.3 0.5 0.2 7.5 1.0
2.|-- core22.fsn1.hetzner.com (2a01:4f8:0:3::6a5) 0.0% 110 0.3 1.7 0.2 39.2 5.2
3.|-- core0.fra.hetzner.com (2a01:4f8:0:3::4e2) 0.0% 110 4.8 4.9 4.8 5.2 0.1
4.|-- ipv6.de-cix.fra.de.as13045.htp.net (2001:7f8::32f5:0:1) 0.0% 110 11.8 11.2 10.6 25.0 1.9
5.|-- 2a02:560:1:e2::1 0.0% 110 16.5 13.1 10.8 41.6 4.3
6.|-- 2a02:560:1:c::1 0.0% 110 15.5 13.5 11.0 57.5 5.2
7.|-- ??? 100.0 110 0.0 0.0 0.0 0.0 0.0
8.|-- xxxx:xxx:xxxx:xxxx:xx:xxx:xx:xxx 0.0% 110 11.5 11.5 11.4 11.7 0.0

pufferueberlauf

Die Frage ist warum hakt es, ich stimme Dir zu, da sieht erst mal nicht aus wie packetverlust (aber vielleicht Zeit einen der langsamen Transfers mit tcpdup/wireshark aufzuzeichnen und dann mal the tcptrace plot anschauen). Ein Punkt kann sein, dass wireguard ueber UDP geht, waehrend Deine Transfers eher TCP nutzen duerften....

mbo77

Dies sind Möglichkeiten, um Probleme mit der MTU und Fragmentierung einzugrenzen.

- Mittels tracepath die MTU entlang einer Route ermitteln:

Code

$ tracepath www.heise.de
 1?: [LOCALHOST]                        0.007ms pmtu 1492
 1:  xxx   												   0.656ms
 1:  xxx   												   0.382ms
 2:  2003:0:8504:800::1                                    5.064ms
 3:  2003:0:f00::b8                                       12.666ms asymm  4
 4:  2003:0:f00::b9                                       10.468ms
 5:  2a02:2e0:12:15::115                                  10.578ms
 6:  2a02:2e0:3fe:0:c::1                                  10.857ms !A
     Resume: pmtu 1492

- Einen ICMP-Ping kann man mitgeben, Pakete einer bestimmten Größe zu schicken und nicht zu fragmentieren:

Code

$ ping -c 1 -M do -s 2000 www.heise.de
PING www.heise.de(www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85)) 2000 data bytes
ping: local error: message too long, mtu: 1492

--- www.heise.de ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

ConiKost

Zitat von mbo77

- Einen ICMP-Ping kann man mitgeben, Pakete einer bestimmten Größe zu schicken und nicht zu fragmentieren:

Würde sagen, dass das passt. Pings bis Größe von 1464 möglich, was am Ende eine MTU von 1492 bedeuten würde. Das wäre mit PPPoE korrekt, da Baby Jumbo Frames vom ISP nicht unterstützt wird.

Zitat von mbo77

Dies sind Möglichkeiten, um Probleme mit der MTU und Fragmentierung einzugrenzen.
- Mittels tracepath die MTU entlang einer Route ermitteln:

Sieht auch für mich absolut okay aus. pmtu 1492 wird gemeldet.