P2411 wäre aber AON?
Beiträge von ConiKost
-
-
PPPoE ist mal wieder ausgefallen, keine Einwahl möglich. Noch jemand betroffen?
<Edit>
Ausfall war von ca. 23:10 bis etwa zwischen 4-5 Uhr.. -
Als letztes Update. Habe meine 3 UniFi AC Pro APs gegen die von MikroTik wAP ax getauscht. Empfang ist sogar noch besser geworden Management mit CAPsMAN läuft einwandfrei.
WiFi7 von UniFi ist raus, das frisst viel zu viel Strom im Vergleich.. (Und ich hab eh keine Geräte mit WiFi7).
-
Neu ist das Thema ja eh nicht. Ranger ist doch seit Jahrzenten für solche Maschen bekannt.
-
Wäre ja sehr zu begrüßen, wenn der Prozess jetzt alle möglichen Geräte ermöglicht.
-
Hat noch jemand bei htp IPv6-Probleme bei Microsoft Teams?
Aktuell scheint Microsoft Teams Probleme zu machen mit IPv6. Während Chats normal funktionieren, lässt sich keine Verbindung zu Videokonferenzen herstellen. Wird IPv6 deaktiviert, lüppt alles.
An eine kaputte IPv6-Konfiguration beim Client will ich nicht glauben, da ich es mit mehreren Routern reproduzieren kann und ebenfalls andere Server via IPv6-Adesse ohne Einschränkung erreichbar sind. Nur Videokonferenzen scheinen ein Problen in Teams zu sein aktuell. Gestern (Mo) hat das noch alles funktioniert.
-
Ich hab mich getraut und es mal ausprobiert, indem ich ROS 7.17 Beta 5 installiert habe, welches heute erschienen ist. Funktioniert soweit ohne Probleme.
Entscheidend ist nur folgendes:
1) Neighbor Discovery muss das M-Flag aktiviert haben.
/ipv6/nd/set managed-address-configuration=yes
2) Pool mit /128 Prefixgröße anlegen, das ist so zwingend notwendig laut MikroTik. Prefix gibt dann die Nutzbaren Adressen an. /112 wäre als Beispiel die letzten 16 Bits FD23::0000 bis FD23::FFFF, welche an Clients ausgegeben werden. Vergebene Beispiel IP an ein Client: FD23::4
/ipv6/pool/add name=mypool prefix=fd23::/112 prefix-length=128
3) DHCPv6-Server Anlegen und den Pool inkl. Interface zuweisen. Optional könenn dann weitere Optionen und ähnliches gesetzt werden.
/ipv6/dhcp-server/add interface=bridge address-pool=mypool
-
- 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.
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.
-
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 -
Kleines Update auf meine Nachfrage bei MikroTik: Damit ist normaler DHCPv6 Support für Clients tatsächlich gemeint. Dann kann man normal DHCP-Optionen und Adressen an IPv6-Clients gezielt ausgeben, wenn man das nicht per SLAAC machen will.
-
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 -
Vermutlich ist das was internes, wie z.B. ein Nimbus-Ticket bei der Telekom
-
Was ist denn ein Camel-Sync
-
Sofern MikroTik nicht was anderes mit der Aussage "DHCPv6 address delegation service" meint, soll in den nächsten ROS 7.17 Beta tatsächlich Unterstützung für DHCPv6 im Bezug auf Adressen kommen. War jedenfalls heute die Antwort von denen auf meine Frage, wie die Roadmap für DHCPv6 stateful support im LAN aussieht.
Da MikroTik per DHCPv6 PD an andere LAN Clients vergeben kann und SLAAC kann, wüsste ich nicht, was das sonst sein soll.
-
Das ist auch kein Dual Stack Lite. Dann würde IPv4 komplett via IPv6 getunnelt werden.
-
Ja, es gibt dafür keine Option leider..
-
Wie ich grad lernen musste, kann offenbar Windows kein Setzen eines statisch Interface Identifier für IPv6 (RFC 7217).. danke Microsoft
. -
Die Idee, dass es eine gute Idee waere eine EInzigartige Hardware ID mit der WEelt zu teilen... Wenn man das z.B. mit dem eigenen Notebook macht ergibt das ein 1A Tracking-Token das funktioniert egal in welchem (IPv6) Netz man sich mit dem Laptop eingelogt hat. Ein Traum fuer Werbetracker... und naiv finde ich, dass die IPv6 macher noche alle vom Guten im Internet ausgegangen sein mussten, dass ihnen diese Missbrauchssart gar nicht in den Sinn kam. Waren wohl noch unschuldigere Zeiten
Dagegen gibt es doch die Privacy Extensions. Du hast dann neben der abgeleiteten die temporäre IPv6-Adresse, welche per Standard genutzt wird. Wobei ich das für die öffentliche IPv6-Adresse garnicht im Sinne hatte. Verstehe aber gut, was du meinst.
Weißt du eigentlich, ob man auf mobilen Geräten in der Google und Apple Welt auch einen statischen Interface Identifier setzen kann?
Ich habe mit EUI64 lokal passend ULA am laufen. Ist ja am Ende eh nur intern für das Netzwerk gedacht. Wobei man nicht vergessen darf, IPv6 ist so alt, da hat man sich das Internet wie heute noch garnicht so vorgestellt
-
Zum Vergleich bei mir das fs.com-Modul an einem F2110 (AON htp):
-
Achsooo. Du meinst also ein statisch vergebener Interface Identifier auf dem Client. Du meinst dann sowas wie z.B. "ip token set ::AA:BB:CC:DD/64 dev eth1" (Gibt vielleicht ja noch andere Wege, nur als Beispiel gemeint).
Persoenlich halte ich EUI64 fuer zu naiv, aber jeder wie er/sie moechte.
Was ist daran naiv? (Ernstgemeinte Frage) Ich weiß, dass irgendein RFC EUI64 als deprecated erachtet, meine ich.
