Beiträge von frank_m

Zitat von aRaphael

HC -> RS G9 - Keine Retr.

RS G9 -> HC - Viele Retr.

Interessant. Ich hab von meinem G8 und G9 Server einen Test gegen den iperf3 Server von WilhelmTel gemacht. Der kann beide Server auslasten. Es gibt zwar ein paar Retransmissions, aber die sind locker um Faktor 20 kleiner, als in der direkten Verbindung der beiden RS.

iperf versucht im TCP Modus natürlich, die Leitung möglichst auszureizen. Das heißt eben, die Leitung wird geflutet, bis es zu Paketverlusten kommt und die TCP Congestion Control Algorithmen zuschlagen. Von daher ist eine gewisse Anzahl Retransmissions normal. Man müsste das mal mit normalen wget Downloads gegentesten.

Ich kann das Phänomen in gewissen Grenzen bestätigen.

Ich hab einen RS 2000 G8 (1 GBit/s) und einen RS 2000 G9 (2.5 GBit/s). Sende ich vom G8 zum G9, gibt es diese Retransmissions. Sende ich vom G9 zum G8, gibt es sie nicht. Erster Verdacht: Es betrifft den Upload des G8 Servers, da der am Limit ist.

Das sieht bei mir ähnlich aus, trotzdem komme ich auf die zu erwartenden Bandbreiten.

root@serv1:~# iperf3 -p 5006 -c <> -6
Connecting to host <>, port 5006
[  5] local <>::1 port 58398 connected to <>::1 port 5006
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  97.6 MBytes   819 Mbits/sec  6244   22.3 KBytes
[  5]   1.00-2.00   sec  96.4 MBytes   809 Mbits/sec  7713   43.2 KBytes
[  5]   2.00-3.00   sec   118 MBytes   986 Mbits/sec  7953   39.0 KBytes
[  5]   3.00-4.00   sec   118 MBytes   986 Mbits/sec  8429   22.3 KBytes
[  5]   4.00-5.00   sec  95.0 MBytes   796 Mbits/sec  5909   32.1 KBytes
[  5]   5.00-6.00   sec   118 MBytes   987 Mbits/sec  8533   30.7 KBytes
[  5]   6.00-7.00   sec   118 MBytes   986 Mbits/sec  7104   32.1 KBytes
[  5]   7.00-8.00   sec   114 MBytes   954 Mbits/sec  6615   62.8 KBytes
[  5]   8.00-9.00   sec  97.5 MBytes   818 Mbits/sec  7725   25.1 KBytes
[  5]   9.00-10.00  sec  90.0 MBytes   755 Mbits/sec  7159   62.8 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.04 GBytes   889 Mbits/sec  73384             sender
[  5]   0.00-10.00  sec  1.03 GBytes   887 Mbits/sec                  receiver

root@serv1:~# iperf3 -p 5006 -c <> -4
Connecting to host <>, port 5006
[  5] local <> port 43230 connected to <> port 5006
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  83.7 MBytes   702 Mbits/sec  3749   53.7 KBytes
[  5]   1.00-2.00   sec  61.8 MBytes   519 Mbits/sec  3387   31.1 KBytes
[  5]   2.00-3.00   sec   119 MBytes   994 Mbits/sec  8564   26.9 KBytes
[  5]   3.00-4.00   sec   116 MBytes   971 Mbits/sec  6198   22.6 KBytes
[  5]   4.00-5.00   sec   118 MBytes   986 Mbits/sec  6463   19.8 KBytes
[  5]   5.00-6.00   sec   117 MBytes   981 Mbits/sec  7471    130 KBytes
[  5]   6.00-7.00   sec   115 MBytes   963 Mbits/sec  8161    120 KBytes
[  5]   7.00-8.00   sec  96.2 MBytes   807 Mbits/sec  7743   28.3 KBytes
[  5]   8.00-9.00   sec  91.2 MBytes   765 Mbits/sec  5990   45.2 KBytes
[  5]   9.00-10.00  sec   117 MBytes   985 Mbits/sec  7501    148 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.01 GBytes   867 Mbits/sec  65227             sender
[  5]   0.00-10.00  sec  1.01 GBytes   864 Mbits/sec                  receiver

Ich fürchte bei den Retransmissions suchen wir an der falschen Stelle. Bei den Tunnelversuchen weiter oben treten sie nicht in signifikanter Anzahl auf, und bei den direkten vServer Verbindnungen schränken sie die Bandbreite nicht dramatisch ein.

Die anderen iperf3 Versuche - auch mit IPv6 Tunnel - zeigen aber nicht solche hohen Retransmission Werte. Ich glaube nicht, dass dort die Ursache zu suchen ist.

Zitat von cheinz71

Ich nehme an die Meldung The repository 'http://debian.froxlor.org stretch Release' does not have a Release file. ist eine Folge des Zertifikatsproblems?

Vielleicht ist das auch das Problem. Bietet froxlor noch Updates für Stretch an? Oder vielleicht nur noch für neuere Distris?

Mit HE Tunneln hab ich eigentlich immer gute Erfahrungen gemacht. Da erreiche ich Bandbreiten bis an den Gigabit Bereich, auf jeden Fall hohe 3stellige Megabit Werte. Das sollte es also nicht sein.

Es scheint ja eher auf Router Seite zu liegen, weniger auf RS Seite. Der Upload vom Router ist langsam, sobald Protokoll 41 in IPv4 Paketen verschickt wird (weil das macht HE ja auch so). Da würde ich als erstes suchen. Vielleicht sieht man was in einem tcpdump? Du hast auch nie mit tc herumgespielt oder mit DiffServ?

Erhöhte Werte auf einzelnen mtr Hops sagen gar nichts aus. Das heißt lediglich, dass der Router ICMP Pakete mit geringer Priorität erzeugt. Er leitet sie aber mit hoher Priorität weiter, denn sonst wären alle Hops dahinter auch langsam. Sind sie aber nicht. Bei einem MTR ist meistens nur der letzte Hop interessant, das Ziel. Wenn die Werte dort in Ordnung sind, ist alles dazwischen irrelevant.

Hast du mal die CPU Auslastung der beteiligten Geräte im Auge behalten? Hast du irgendwelche iptables oder traffic Shaper Regeln auf deinem Router aktiv? Es fällt ja auf, dass auch die HE Tunnel Ergebnisse mäßig sind.

Welcher Router kommt denn zum Einsatz? Hast du testweise eine andere Gegenstelle für die Verbindung? Wie sieht die IPv6 Performance des RS 500 ins Internet aus?

Welche Adressen nutzt du denn für IPv6? Aus dem /64 Netz des RS 500? Hat nur der Router eine IPv6 oder verteilst du lokal auch noch Adressen an die Clients des Routers?

Zitat von Kumotaku

Aber es ergibt für mich einfach in der heutigen Zeit keinen Sinn, da doch alle Dateien vorhandne sind und die müssen lediglich in eine Datenbank eingefügt werden.

Die Dateien müssen nicht in die Datenbank eingefügt werden. Die Datenbank hat mit diesen Dateien gar nichts zu tun, ihr Inhalt ist ein völlig anderer, der in keiner Datei gespeichert wurde. Wird es dir jetzt klar, warum diese Dateien dir überhaupt nicht weiterhelfen?

Diese Dateien sind auf allen Wordpress Installationen gleich. Sie generieren die Webseite, indem sie die Inhalte aus der Datenbank auslesen und aufbereiten. Der Inhalt der Datenbank ist das entscheidende für die Webseite, nicht die Dateien.

Das Problem ist, dass man es auch auf dem Client braucht ... Mit mobilen Endgeräten hinter restriktiven Firewalls schwierig.

Jau, der sieht nett aus.

Zitat von Skulduggery

Dann sparst du dir faktisch schon den ganzen pain den du hier hast und als Kirsche auf der Sahne brauchst du nur ganze 6 Zeilen Konfiguration für deine Clients.

Um das Routing muss er sich auch bei Wireguard schon noch selber kümmern. Dazu UDP only und die IP Konfiguration ... Ja, die Performance ist besser, wenn man mit den ganzen Einschränkungen leben kann.

Zitat von Skulduggery

Theoretisch gibts noch den EdgeRouter X / Lite für weniger Geld. Da bin ich bei Recherchen recht häufig auf die Zahl 100-150 Mbit gestoßen.

Ein Raspi 4 schafft 250 MBit/s. Preis/Leistung vermutlich unschlagbar.

Ich glaube übrigens, dass es in Post 1 auch schon einen erfolgeichen Versuch gab, nämlich den auf 10.0.0.1. Nur durch das Hinzufügen der gleichen VLAN ID auf beiden Seiten dürfte die Kommunikation nicht gestört worden sein.

Wo ist denn jetzt das Problem? Nur die Anzeige "nicht identifiziertes Netzwerk"? Weil alles andere sieht doch gut aus.

Wenn man einen Webserver hat, kann man dort auch Projekte wie ownDynDNS installieren:

https://github.com/fernwerker/ownDynDNS

Darüber sollte ein Update mit üblichen http Aufrufen möglich sein, das könnte man vermutlich auch mit ddclient hinbekommen - oder einfach mit curl oder wget.

Zitat von michaeleifel

Mein Zweck dahinter ist, dass ich mich nicht mit blöden Routern rumschlagen muss die sich entscheiden ULA anders zu routen, schon die besten Stories erlebt.

Bei ULA macht man natürlich NAT6, das kam in meinem letzten Post vielleicht missverständlich rüber.

Zitat von michaeleifel

Da mir ein /64 Ipv6 netz zugeordnet ist, nutze ich einfach das Subnetz und trickse die Router aus und bisher hatte ich keinen Fall wo das nicht geklappt hat.

Aber wenn du NAT6 mit diesen Adressen machst, dann sehen vorgeschaltete Router die gar nicht mehr.

Es war nicht bei netcup, sondern bei einem anderen Webanbieter, aber da hatte ich auch mal so eine Warnung, und anschließend waren alle Daten weg. Ich hatte erfreulicherweise ein Backup, aber ärgerlich war es trotzdem.

Das war dann der Moment, wo ich mir geschworen habe, nie mehr solche Webhosting Angebote zu nutzen, sondern nur noch RS/VPS Systeme. Da entscheide ich selber, wann was gelöscht wird.

Wobei Microsoft den TTL Wert nicht abprüft. Die Einträge funktionieren auch mit TTL 86400.

Zitat von shack

Dort war unter APN "internet.v6.telekom" eingetragen. Kurz im Internet geschaut und statt "internet.v6.telekom" jetzt "internet.telekom" eingetragen.

Unglaublich, dass die tatsächlich einen IPv6 Only Ansatz durchziehen. Eigentlich finde ich das ja gut. Aber die Mobilfunkprovider haben sich ewig geziert, und jetzt kann es nicht schnell genug gehen ...

Zitat von shack

Address = 10.6.0.1/24, 2001:8d8:1801:81c5:dada::1/80

Ist die IPv6 Adresse aus deinem Prefix Bereich? Weil ansonsten bekommst du Probleme mit dem Routing. Frage: Warum machst du NAT auf IPv6, wenn du mit einer öffentlichen IPv6 arbeitest? Da kannst du auch vollwertig routen. Oder alternativ eine ULA Adresse nehmen.

Nachtrag: Wenn du hier mit öffentlichen IPs ohne NAT arbeitest, musst du natürlich auch NDPP ans Laufen bringen.