wir haben heute zwei neue Knoten in Betrieb genommen und danach festgestellt das wir manche IPv4 Hosts nicht erreichen / pingen können.
Aufgefallen ist das zuerst mit einer Unitymedia Business IPv4 Adresse (kein Dualstack(!)). Hierhin verbindet eigentlich mein VPN tadellos. Nicht so, wenn ich in der Freifunkzelle hänge.
Ein Traceroute kommt bis zum Exit-Node ( 185.66.192.128 ) und nicht weiter.
Andere Adressen wie 8.8.8.8 sind problemlos erreichbar.
dropbox.com z.b. hingegen wiederum nicht.
Ein Knotenbetreiber in der Nachbarschaft der seine schon länger im Betrieb hat, hat die gleichen Probleme.
Was für eine IP-Adresse ist denn das, die Du da NICHT erreichen kannst?
(kannst die letzte Gruppe gern „anonymisieren“).
Soweit ich weiss, haben nämlich einige Freifunk-Domains historisch noch „Collisions-Netze“, die sie eigenltich gar nicht nutzen dürften, weil sie die IP-Adresse gar nicht besitzen und es auch keine RFC1918-Bereiche sind.
Oft waren das aber Bereiche von irgendwelchen (bestimmten) US-Universitäten.
Zum Sinn/Unsinn eines solchen Vorgehens mag ich mich jetzt nicht äußern, aber zumindest könnte es etwas ähnliches sein.
Wie geschrieben: eine aus dem Unitymedia Spektrum, konkret: 46.252.137.* - aber das selbe verhalten taucht auch bei z.b. dropbox.com auf. Weder auf dem Notebook, noch per Handy noch per Traceroute kann ich dropbox.com, „meine“ ip und andere Dienste erreichen.
ich habe es mal mit der 46.252.137.1 probiert:
In der Tat, aus der Domain „Rheinufer“ nicht erreichbar.
bei 185.66.192.128 ist „Schluss“.
Von der Domain „Frankfurt“ aus geht’s.
Bestehen die Probleme heute Morgen immer noch? Zur Zeit kann ich die Adresse ohne Probleme aus der Domäne Möhne heraus erreichen. Das spricht eher gegen ein Rheinland Backbone Problem. Kann das jemand einmal prüfen?
Das dazu gehörige Präfix ist jedenfalls vom Backbone gelernt worden und ein traceroute von Frankfurt aus nach 46.252.137.1 zeigt keine Probleme. Auch ein Ping nach www.dropbox.com funktioniert problemlos.
Muss ich leider bestätigen, habe gerade meinen Freifunk Router in betrieb genommen und stelle fest das es keine IPv4 Adresse gibt.
Getestet mit diversen „welche IP habe ich“ Seiten, einige laden erst gar nicht und diejenigen die (vernünftiger weise) IPv6 unterstützen geben mir keine IPv4 an.
Wenngleich selten,aber immer mal wieder.
Möchte Ich auch bestätigen.
Die Fehler sind der Kategorie „Blinker“ und damit exakt der Art die keiner gerne sucht, weil eher schwierig zu finden.
Mir kommen so folgende Gedanken zu den Dingen die Ich selber ab und an erlebe:
keine IPv4… Scope „alle“, alles vergeben ? Oder hakt der Tunnel in dem Moment. Selten.
extrem langsammer Seitenaufbau, Sättigung der Leitungen ? In den Statistiken sieht man ja nur wieviel durchgeht - aber nicht die Kapazität. Haben wir hier peaks über sinnvoller Auslastung ? - schon was öfter.
DNS timeouts (ehrlich gesagt noch nicht strukturiert nachvollzogen ob v4/v6 relevant), auch bei mehrfachem reload - DNS Dienst tot ? - sehr seltener Effekt.
irgendein Ziel „mag nicht“ - es gibt keinen Seitenaufbau oder Dienste (Dropbox…) kommen nicht zu Stande. Als würde es am NAT klemmen.
Ich würde es als „undramatisch, aber steigende Tendenz“ beschreiben.
Und wie Ich schrieb: Dramatik hält sich im Rahmen, Effekt scheint aber zuzunehmen. Nicht nur bei mir.
Über das aktuelle Routing kann Ich nix sagen.
In meiner Vermutung würde Ich dir Recht geben, ist aber Kristallkugel.
Da mir Zusammenhänge oder Parallelen unklar sind, poste Ich es hier mal als „Wasserstandmeldung“.
wir haben in den letzten Tagen mehrere Dinge korrigiert.
habe ich gestern in der Konfiguration der DHCP-Server der Domäne Rheinufer IP-Adressen nachgelegt. Diese waren zeitweise restlos vergeben. Daher gab es keine IPv4 Adresse.
haben wir die MTU der Tunnel zwischen Supernodes und Backbone auf 1412 Bytes herab gesetzt. Grund dafür ist, dass jederzeit die Situation auftreten kann das GRE in GRE getunnelt wird. So passt es nun.
haben wir im Rheinufer TCP MSS Clamping entsprechend auf 1412 Bytes gesetzt.
Zu den Kapazitäten ist zu sagen, dass der Backbone aktuell über 6x 1Gbit/s verfügt und wir < 100Mbit/s im Peak verwenden. Über Supernodes möchte ich keine Aussage treffen da diese virtuelle Systeme sind und sich Netzwerkanbindung teilen.
Könnte es sein, dass es mit dem MacShuffling zu tun haben, das Apple seit dem neusten IOS-Release betreibt? Dagegen könnte eine Verringerung der Lease-Time helfen.
Und was Clamping/MSS/MTU-Pass-Discovery anbelangt: das wird die VPN-Tunneler wohl bis St.Nimmerlein verfolgen.
habe gerade noch einen Parameter am DHCP Server hochgesetzt. So wie es war wollte er nicht mehr als 1000 Leases rausgeben. Habe außerdem nun pro Supernode 50.000 IP-Adressen konfiguriert und die Lease-Time auf 3h reduziert (vorher 12h).
