die Maßeinheiten sind ma schon immer suspekt gewesen, demnach wär ich 6 Fuß hoch,
also keine 3 Käse hoch
es sei denn 1 Käse ist 2 Fuß hoch
die Maßeinheiten sind ma schon immer suspekt gewesen, demnach wär ich 6 Fuß hoch,
also keine 3 Käse hoch
es sei denn 1 Käse ist 2 Fuß hoch
Hast du mal die CPU Auslastung der beteiligten Geräte im Auge behalten?
CPU ist nicht das Problem, der RS hat 2 Cores und macht eigentlich nebenbei so gut wie nichts anderes;
der Router - eine ZBOX - hat 4 Cores, ist auch nicht das Problem; (sonst hätt es ja nie gehen dürfen)
Hast du irgendwelche iptables oder traffic Shaper Regeln auf deinem Router aktiv?
die einzigen - welche im entferntesten darunter fallen könnten
am vServer:
bei IPv6:
-A INPUT -i eth0 #vSrver-IPv6-Prefix# -p icmpv6 -m limit --limit 2/sec --limit-burst 4 -j ACCEPT
bei IPv4:
-A INPUT -i eth0 -p icmp -m limit --limit 2/sec --limit-burst 4 -j ACCEPT
ein traceroute6 von irgendwo nach Hause endet am vServer, das hatte ich aber bereits im Januar schon so; sprich mein Netz zu Hause ist abgeschottet;
ich hab am vServer folgende beiden ip6tables-Rules
Es fällt ja auf, dass auch die HE Tunnel Ergebnisse mäßig sind.
das ist zwar richtig, aber hier gehört die Infrastuktur am Tunnelaustrittspunkt auch nicht mir alleine;
Nur mal etwas laut gedacht, wäre es möglich, dass einer der Router, die auf dem Weg zwischen netcup und mir zu Hause
die IPv4-Pakete mit dem 6in4-Protokoll (proto 41) im Header etwas drosseln - niedriger priorisieren?
(soetwas wäre f. mich nach bisherigem Wissenstand die einzige Möglichkeit, weil als echtes IPv4 habe ich die Bandbreite)
ich erwarte mir jetzt nicht unbedingt die vollen 200 MBit/sec aber nicht mal ¼ davon finde ich zuwenig;
etwa die Hälfte (rund 100 MBit/sec) würde ich gerne haben;
aRaphael leider nein; ich hab sie von default 1480 mal auf 1472 gesetzt - klar auf beiden Seiten; ändert nichts;
beim unteren IPv4-Teil, ist Hop 1. der vom ISP gestellte Router, dort ist WANseitig meine public IPv4 und LANseitig eine RFC1918-IPv4,
und dieser läßt das Protokol 41 (IPv6) durch - eh klar sonst ginge es gar nicht;
und Hop 2. beim ISP
[der RFC1918-IPv4 habe ich einen Namen gegeben (Eintrag im hosts-File)];
[oder so mit IPs statt Namen]
der umgekehrte MTR vom vServer nach Hause sieht so aus
irgendwie finde ich Hop 3. (144.208.208.138) zuviel?
zum vServer (von links nach rechts)
rfc1918, 212.33.34.37, 212.33.35.42, 193.203.0.19, 144.208.208.132, 144.208.208.137, 144.208.211.11, vServer
nach Hause (von rechts nach links)
home, 212.33.34.38, 212.33.35.41, 193.203.0.43, 144.208.208.133, 144.208.208.136, 144.208.208.138, 144.208.211.30, 37.120.184.3
DerRené ja stimmt, das Ergebnis bestätigt eigentlich obiges;
der vServer hat volle Geschwindigkeit auch mit IPv6; einzig der IPv6-Tunnel lahmt, warum?
iperf3 -c speedtest.serverius.net -p 5002 -R
bzw.
iperf3 -c speedtest.serverius.net -p 5002
oben kommt die maximale Bandbreit im Upload zum Tragen; unten dennoch wie bereits Eingangs-Posting, nur rund 35 MBit/sec
auch hier nur maxmimal etwa 35 MBit/sec; wobei hier kann das am iperf3-Server liegen, weil mit IPv4 habe ich da auch nicht mehr ...
Welcher Router kommt denn zum Einsatz?
mein Router ist ein Mini-PC (ZBOX) mit einem vollst. Linux, analog dem RS 500 - ich verwende CentOS;
Hast du testweise eine andere Gegenstelle für die Verbindung?
einzig einen anderen vServer hier ...
Wie sieht die IPv6 Performance des RS 500 ins Internet aus?
kann ich leider nicht testen;
(habe nur vServer bei netcup und mein Netzwerk zu Hause)
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?
ich habe ein zusätzliches IPv6-/64-Subnetz, welches ich zu Hause nutze;
der Tunnel wird am vServer so aktiviert (das analoge Gegenstück befindet sich am Router)
/sbin/ip tunnel add sit1 mode sit remote #home-IPv4# local #eth0-IPv4# ttl 255
/sbin/ip link set sit1 up mtu 1480
/sbin/ip addr add #sit1-IPv6# dev sit1
/sbin/ip route add #home-LAN-prefix# via #sit1-IPv6-router-at-home# dev sit1 metric 1
#sit1-IPv6# und #sit1-IPv6-router-at-home#
sind einfach ein /64 nach RFC4193 mit ::1 und ::2
so habe ich das von Anfang an im Januar 2021,
und habe daran auch nichts geändert;
Hallo,
ich betreibe auf einem RS 500 G8 einen 6in4-Gateway-Server einzig f. mich alleine; dieser vServer tut auch sonst kaum was anderes;
vor etwa 1 Stunde hatte ich ihn neu gestartet (das ist aber nicht das Problem), nur die Erkl. f. die Ausgabe von uptime
19:44:31 up 59 min, 1 user, load average: 0.02, 0.01, 0.00
im Jan. 2021 sah der Geschwindigkeitstest bei ipv6-test.com so aus:
im April 2021 kam ein Upgrade auf meinen Internetzugang,
da sah dann der Geschwindigkeitstest so aus:
seit geraumer Zeit fällt mir auf, dass es bei Verb. über IPv6 etwas hackt ...
dann der Geschwindigkeitstest:
wieso?
ich machte mich auf die Suche, und machte mit iperf3
den Test
am vServer startete ich iperf3 -s
am Router jeweils
iperf3 -c eth0-IPv6 -R
iperf3 -c sit1-IPv6 -R
iperf3 -c eth0-IPv4 -R
(eth0-IPv4 bzw. eth0-IPv6 sind die IP(v6)-Adressen vom eth0-Device des vServers und
sit1-IPv6 ist die IPv6-Adresse vom sit1-Device des vServers)
hier das Ergebnis - die Anzeige am vServer
bei IPv4 würde ich die Bandbreite haben (3ter bzw. unterster Teil), wieso aber nicht bei IPv6?
was ja den selben Weg nehmen muss, da es ja mein IPv6-Tunnel ist; ich habe sonst kein IPv6 ...
(mein ISP ist nach wie vor und das auch die nächsten Jahre IPv4only)
was bremst hier IPv6 derart aus?, und wieso macht sich das derart bemerkbar - nur rund 1/6-1/5 der Bandbreite;
es ging ja schon mal siehe Geschwindigkeitstest vom April 2021 weiter oben;
hier IP6tables vom vServer:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
# Filter all packets that have RH0 headers
-A INPUT -m rt --rt-type 0 -j DROP
-A FORWARD -m rt --rt-type 0 -j DROP
-A OUTPUT -m rt --rt-type 0 -j DROP
# Enable Link-Local addresses
-A INPUT -s fe80::/10 -j ACCEPT
-A OUTPUT -s fe80::/10 -j ACCEPT
# Enable multicast
-A INPUT -d ff00::/8 -j ACCEPT
-A OUTPUT -d ff00::/8 -j ACCEPT
# Allow anything on the local link
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
#
# Block totally from internet
# - Terdo: 2001:0::/32
# - 6to4: 2002::/16
# - ...
#
# [INPUT-chain]
#
-I INPUT -i eth0 -s 2001:0::/32 -j DROP
-I INPUT -i eth0 -s 2002::/16 -j DROP
#
# [FORWARD-chain]
#
-A FORWARD -i eth0 -s 2001:0::/23 -j DROP
-A FORWARD -i eth0 -s 2002::/16 -j DROP
#
#
# Allow all from 6in4-device temp.
-I INPUT -i sit1 -j ACCEPT
# Allow anything out on the internet
-A OUTPUT -o eth0 -j ACCEPT
# Allow established, related packets back in
-I INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow anything out on the 6in4 tunnel
-A OUTPUT -o sit1 -j ACCEPT
# Allow established, related packets back in
-I INPUT -i sit1 -m state --state ESTABLISHED,RELATED -j ACCEPT
# Enable ICMPv6 from internet and 6in4 tunnel
-A INPUT -i eth0 -d #eth0-IPv6# -p icmpv6 -m limit --limit 2/sec --limit-burst 4 -j ACCEPT
-A INPUT -i sit1 -d #eth0-IPv6# -p icmpv6 -j ACCEPT
-A INPUT -i sit1 -d #sit1-IPv6# -p icmpv6 -j ACCEPT
# Enable TRACEroute to me from internet and 6in4 tunnel
-A INPUT -i eth0 -d #eth0-IPv6# -p udp --sport 32769:65535 --dport 33434:33523 -m limit --limit 2/sec --limit-burst 4 -j ACCEPT
-A INPUT -i sit1 -d #eth0-IPv6# -p udp --sport 32769:65535 --dport 33434:33523 -j ACCEPT
-A INPUT -i sit1 -d #sit1-IPv6# -p udp --sport 32769:65535 --dport 33434:33523 -j ACCEPT
# Enable SSH (private)
-A INPUT -i eth0 -m tcp -p tcp --dport 22 -j DROP
-A INPUT -i sit1 -s #LAN-IPv6-prefix# -m tcp -p tcp --dport 22 -m state --state NEW -j ACCEPT
# Enable 6in4 Tunnel traffic
-I FORWARD -i eth0 -o sit1 -d #LAN-IPv6-prefix# -m state --state ESTABLISHED,RELATED -j ACCEPT
-I FORWARD -i sit1 -o eth0 -s #LAN-IPv6-prefix# -j ACCEPT
# Enable DNS
-A INPUT -i eth0 -d #eth0-IPv6# -m tcp -p tcp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -i eth0 -d #eth0-IPv6# -m udp -p udp --dport 53 -j ACCEPT
-A INPUT -i sit1 -d #eth0-IPv6# -m tcp -p tcp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -i sit1 -d #eth0-IPv6# -m udp -p udp --dport 53 -j ACCEPT
-A INPUT -i sit1 -d #sit1-IPv6# -m tcp -p tcp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -i sit1 -d #sit1-IPv6# -m udp -p udp --dport 53 -j ACCEPT
# Enable HTTP(S)
#-A INPUT -i eth0 -d #eth0-IPv6# -m tcp -p tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -i eth0 -d #eth0-IPv6# -m tcp -p tcp --dport 443 -m state --state NEW -j ACCEPT
#-A INPUT -i sit1 -d #eth0-IPv6# -m tcp -p tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -i sit1 -d #eth0-IPv6# -m tcp -p tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -i sit1 -d #sit1-IPv6# -m tcp -p tcp --dport 443 -m state --state NEW -j ACCEPT
# Log all other
-A INPUT -j LOG --log-prefix "IPv6[IN]: " --log-level crit
-A FORWARD -j LOG --log-prefix "IPv6[FWD]: " --log-level crit
-A OUTPUT -j LOG --log-prefix "IPv6[OUT]: " --log-level crit
COMMIT
Alles anzeigen
wobei hier bei der Bandbreitendiskussion man unterscheiden muss,
ob es sich um die Bandbreite vom vServer weg od. zum vServer hin handelt;
zum vServer hin ist die mehr als dicke,
aber vom vServer weg ist eher die Anbindung von netcup selbst das Problem;
Oder liegt das an irgendeinem heraus gepatchten "Feature" von Ungoogled Chromium?
Ne an unfehlbaren Admins od. katastrophalen Programmierern
Als unter Dauerlast landen meine VPS200 bei rund 100Mbit/s...
in welche Richtung:
von Deinem vServer über die Grenzen von netcup hinweg,
oder zu Deinem vServer?
kann hier mal jemand die umgekehrte Richtung testen:
ich habe folgendes festgestellt:
ein Download am vServer flutscht in affenartiger Geschwindigkeit,
macht man aber hingegen z.B. zu Hause einen Download vom vServer,
dann geht das nur mit einem Bruchteil der Geschwindigkeit - warum?
das weiter oben von joas verlinkte liefert direkt von zu Hause
aber schon die volle Geschwindigkeit;
damit ist mein IPv6-in-IP Tunnel etwas gröber ausgebremst, obwohl dieser noch im Jan. diesen Jahres die volle Geschwindigkeit hatte;
weiß hier jemand von [netcup] Claudia H. etwas dazu, ob die Anbindungen von Seiten netcup in Richtung 'upload'
einfach 'dicht' sind?
Leergeld
hat das was mit Leerverkäufen zu tun?
Da hat man einmal etwas nicht direkt verlinkt…
schon klar, ändert aber nix daran, dass die Preisangaben f. Endverbraucher mit dem Zusatz 'exkl. MwSt.' unfug sind;
sollte des wirklich eine Konkurrenz zu Amazon werden, dann braucht es schon mal ein Auslieferungslager in Österreich,
wenn sie schon bei den Artikeln Angaben zu CO2 machen, oder wird des mal zur Abwechslung mit der Bahn mit Ökostrom¹ transportiert?
¹ die Dt. Bahn ist nebenbei erwähnt nicht mit Ökostrom unterwegs;
Ausnutzung der Kleinunternehmerregelung nach § 6 Abs 1 Z 27 Umsatzsteuergesetz (UStG)?
Kleinunternehmer mit Mrd. Umsatz? und des is sicher der Paragraph nach Dt. Recht, oder?
Aber da liegt wohl derzeit einiges im Argen:
bei mir nicht, ich komm sowohl auf .de als auch .at hin;
Ja genau, weil lt. unser derart gut informierten Qualitätspresse, is des ab heute auch in Österreich;
aber wenn da die MwSt. hinzukommt, dann ist des ein gewaltiger Flop, würd ich mal sagen
Amazon hat Konkurrenz bekommen - aus der Schweiz - das Auslieferungslager ist in Krefeld (Dtl.): Galaxus
ist des wirklich so, dass zu den Preisen die MwSt. hinzukommt, weil überall die Angabe 'exkl. MwSt.' steht?
Wenn das nächste iPhone nur noch IPv6 könnte, wären die Provider immerhin plötzlich ganz schnell bei IPv6 am Start…
od. Apple pleite, weil dann jeder auf Android umsteigt;
wenn ma schon dabei sind, Amazon hat auch ein ganzes Klasse A Netz, was aber in mehrere Fragmente unterteilt ist
NetRange: 3.128.0.0 - 3.255.255.255
CIDR: 3.128.0.0/9
NetName: AT-88-Z
NetHandle: NET-3-128-0-0-1
Parent: NET3 (NET-3-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Amazon Technologies Inc. (AT-88-Z)
RegDate: 2018-06-25
Updated: 2018-09-13
Ref: https://rdap.arin.net/registry/ip/3.128.0.0
Alles anzeigen
NetRange: 3.0.0.0 - 3.127.255.255
CIDR: 3.0.0.0/9
NetName: AT-88-Z
NetHandle: NET-3-0-0-0-1
Parent: NET3 (NET-3-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Amazon Technologies Inc. (AT-88-Z)
RegDate: 2017-12-20
Updated: 2021-07-22
Comment:
Alles anzeigen
dass hier im unteren Fragment als 'Comment' zwei x509-Zertifikate im PEM-Format angegeben sind, ist dann etwas Strange
Zertifikat 1
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 18392486095260960288 (0xff3f3ca7f4574620)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
Validity
Not Before: Jun 7 12:09:14 2019 GMT
Not After : Jun 6 12:09:14 2020 GMT
Subject: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:cd:a0:...:e4:b5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
ED:A7:BA:91:54:30:84:8D:F9:FB:0A:B6:CF:AD:C4:21:62:A1:AD:10
X509v3 Authority Key Identifier:
keyid:ED:A7:BA:91:54:30:84:8D:F9:FB:0A:B6:CF:AD:C4:21:62:A1:AD:10
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
31:4f:47:...:41:22
Alles anzeigen
Zertifikat 2
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
11:e0:85:84:30:90:60:74:2c:bd:5c:47:12:65:7a:51:4c:e2:dd:1a
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=CA, L=Palo Alto, O=Amazon Web Services, OU=AWSConsoleProxy, CN=console.aws.amazon.com/emailAddress=awsc-spacebird@amazon.com
Validity
Not Before: Apr 20 22:24:40 2021 GMT
Not After : Apr 20 22:24:40 2022 GMT
Subject: C=US, ST=CA, L=Palo Alto, O=Amazon Web Services, OU=AWSConsoleProxy, CN=console.aws.amazon.com/emailAddress=awsc-spacebird@amazon.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d8:d4:...:92:d5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
81:6A:B5:F2:41:29:F8:C3:9E:5F:52:70:B5:FB:13:00:1C:48:8B:71
X509v3 Authority Key Identifier:
keyid:81:6A:B5:F2:41:29:F8:C3:9E:5F:52:70:B5:FB:13:00:1C:48:8B:71
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
29:2c:86:...:9e:73
Alles anzeigen
irgendwie glaubt ma fast, dass jeder Klobesen im Pentagon a eigene IPv4 hat ...
bei mehr als 5 Klasse A-Netzen(!)
NetRange: 7.0.0.0 - 7.255.255.255
CIDR: 7.0.0.0/8
NetName: DISANET7
NetHandle: NET-7-0-0-0-1
Parent: ()
NetType: Direct Allocation
OriginAS:
Organization: DoD Network Information Center (DNIC)
RegDate: 1997-11-24
Updated: 2006-04-28
Ref: https://rdap.arin.net/registry/ip/7.0.0.0
Alles anzeigen
dazu die Netze 11.0.0.0/8, 21.0.0.0/8, 22.0.0.0/8, 26.0.0.0/8, 28.0.0.0/8, 29.0.0.0/8 und was weiß der Geier noch welche Netz
AT&T hat nur schlappe 16777216 IPv4-Adressen:
NetRange: 12.0.0.0 - 12.255.255.255
CIDR: 12.0.0.0/8
NetName: ATT
NetHandle: NET-12-0-0-0-1
Parent: NET12 (NET-12-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: AT&T Services, Inc. (ATTW-Z)
RegDate: 1983-08-23
Updated: 2013-12-19
Comment: For abuse issues contact abuse@att.net
Ref: https://rdap.arin.net/registry/ip/12.0.0.0
Alles anzeigen
des wird eng mit IP-Telephonie und mehr als ¼ Mrd. Telephonanschlüsse?
zum Thema 'Heilige Kuh', was macht der Ford Motor Company mit einem ganzen Klasse A-Netz?
NetRange: 19.0.0.0 - 19.255.255.255
CIDR: 19.0.0.0/8
NetName: FINET
NetHandle: NET-19-0-0-0-1
Parent: ()
NetType: Direct Assignment
OriginAS:
Organization: Ford Motor Company (FORDMO)
RegDate: 1988-06-15
Updated: 2010-05-07
Ref: https://rdap.arin.net/registry/ip/19.0.0.0
Alles anzeigen
bei der Verschwendung durch die Vergabestelle ...
da hätten wir noch genug IPv4 bis ins 4te Jahrtausend
(ma braucht keine IP-Adresse reservieren,
nur weil ma eine auf sein T-shirt, seine Blechkiste od. sonstwas druckt, klebt, graviert, ...)
tab des dass jeder Plunder eine IP braucht, aber ohne Strom nix damit anfangen kann, ist aber hinlänglich bekannt
Damit hast du unter MBR bootfähige GPT Partitionstabellen
entspricht das nicht ohnehin der Standarddefinition, dass bei GPT-Platten der Abwärtskompatibilität wegen eine ganz normale MBR Partitionstabelle vorhanden ist, welche Du besser mit alten MBR-only-Tools nicht angreifst/veränderst?
das mit EFI/SecureBoot ist eine andere Geschichte;