gestern (9.1.24) ab ca. 23:00-23:50 Uhr sowie heute 10.1. ab 17:29 sind/waren manche Archlinux Mirrors wenn via FFRL erreicht, nur mit 10-100KB/s erreichbar. Bei Verbindung direkt über den Kabelrouter, ohne FF dazwischen, sind die Mirrors bei mir mit (Edit: ~2300KB/s) erreichbar (max. des Anschlusses).
Das Problem scheint abhängig davon zu sein wo/wie ausgeleitet wird:
betroffen:
185.66.195.1 → 185.66.193.0 → as8422 (194.146.118.3)
185.66.195.1 → lwlcom (185.1.74.19)
185.66.195.1 → dfn bcix (193.178.185.42)
aufgerufen habe ich mirror netcologne, ftp-stud esslingen, halifax rwth aachen, mirrors.rit.edu sowie berlin-ak ftp media ccc.
Der Packetloss ist auch relativ hoch 87% bei 185.66.195.1 sonst <10% , mtr o.ä. kann ich aber nicht posten wegen weil zu viele Links…
Ich habe nahe an unserem Core von FFDdorf da gar kein Problem.
207871 > 201701 > Decix > AS553
Sättigt 1Gbps denke ich mal.
Wenn ich das aus dem Mesh heraus mache zu Hause am DSL geht das auch. Natürlich viel langsamer. Aber schon noch 6+MB/s .
VIelleicht ist es auch gerade weg.
mirror.rus.uni-stuttgart.de hat bei mir via FF 50KB/s und geht von AS201701 via BCIX und DFN nach Stuttgart, ohne Freifunk sind es 2.4MB/s (dann aber via DECIX und Belwue)
mirror.selfnet .de hat 1.2MB/s geht aber auch via DECIX (185.66.195.1 → * → 87.245.232.233 (AS9002)-> 80.81.192.175 (DECIX belwue)
stud.hs-esslingen hat das Problem geht allerdings via AS50629 zum DECIX
Zu welcher Adresse in AS553 hast du gemessen? Kannst du mal ein mirror testen der via BCIX geroutet wird zb. ftp.halifax.rwth-aachen.de ?
Edit: Kannst du auch einmal zu community ix testen, z.B. debian.mirror.root.lu?
Spekulation: Könnte es sein, dass der Community-IX das Bottleneck ist? Laut Website Sponsors - Community-IX verfügt er insgesamt über eine Anbindung von 200G und nochmal 60G für peering mit communities, das verteilt sich aber auf 5 Standorte. Die Auslastung liegt derzeit bei 120G (https://www.community-ix.de/ixp/grapher/ixp?period=day), wenn nun die Last ungleich verteilt ist, könnte irgendwo schlicht „voll“ sein. Mit Ausnahme von netcologne, sind die „problematischen“ AS direkt am Community-IX verbunden bzw. haben peeringports dort.
Einen Link (Grafana oder so) zur Auslastung der einzelnen Standorte habe ich nicht gefunden.
Edit: mittlerweile bin ich mir nicht mehr so sicher ob community-ix das Problem ist oder vlt. eher die Verbindung FFRL → Community-IX, traceroute gibt je nach Ziel im sekunden Takt andere Routen aus, vodafone und wobcom, sowie vodafone und retn wechseln häufig.
Update: Gestern Nacht (irgendwann nach 1 Uhr) war das Problem weg, jetzt ist es wieder beobachtbar 185.66.195.1 (und ffmsd-gateway c1024). Da ich den Router neugestartet hatte lief der traffic gestern Nacht zeitweise über 185.66.195.0 (und ffmsd-gateway des1) . Ob es also an der Schwachlastzeit oder am gw lag kann ich nicht sagen. Achso und bisher habe ich nur für ipv4 getestet.
Da aber auch zum gw schon packet loss ist, bin ich mir nicht sicher ob die Störung bei FFRL, bei FFMSD oder wo anders ist.
Hi. Wir haben eventuell ein Problem am Berliner Standort.
Ist das Problem nur bei Tunneln über Berlin vorhanden? Den Community-IX haben wir aber afaik nur über Berlin erschlossen.
Ist das Problem nur bei Tunneln über Berlin vorhanden?
Falls 185.66.193.0 auch in Berlin ist, dann ja. Bzw. es ist nur 185.66.195.1 betroffen, ich weiß aber nicht welcher Standort das ist.
Edit: korrigiert
Ist 185.66.195.1 das Ende des Tunnels von Münsterland zu FFRL im Speedbone Berlin?
Ich kenne die Topologie nicht genau, scheinbar scheint aber all mein Traffic via 185.66.195.1 zu gehen. Allerdings bestehen laut grafana Grafana von meinem gateway c1204 auch Verbindungen zu ffrl-dus und ffrl-fra.
Update:
Der ausgehende Traffic des FF-Routers geht immer über Berlin, der Downstream kommt, behaupten online traceroute Tools, aber auch direkt aus fra oder dus.
In der Ansible config von den Gateways für FFML stehen 6 Tunnel, aber für Berlin ist ‚bgp_local_pref: 201‘ gesetzt. Die anderen bekommen, dann wenn ich bird.conf richtig verstehe, ‚bgp_local_pref: 200‘ als default.
Dh. im Momment sind zwar auch Tunnel nach dus und fra vorhanden, das bgp routing präferiert aber für alle ausgehenden Pakete Berlin. Betroffen sind ‚c1024‘, ‚des1‘ und ‚corny‘ von FFML. Ist das so beabsichtigt oder sind das Altlasten? In der config einiger anderer Gateways von FFML ist die Einstellung auskommentiert.
Das erklärt also warum aller Traffic via Berlin geht, aber noch nicht warum die Bandbreite manchmal ~10KB/s ist. Da ich kein Zugriff auf das Gateway habe, kann ich die anderen Tunnel nicht testen.
Edit: vgl.
@MPW Kannst du dir die Einstellung mal anschauen, also ob bgp_local_pref: 201 entfernt werden kann, so dass BGP alle Tunnel verwendet, je nach dem welcher näher/günstiger ist?
=== Tunnel Berlin/Community-IX ===
Situation ist unklar. Da es wegen der Gateways zusätzlich paketloss gibt, ist der Effekt von mir aus schwer messbar, die betroffenen Routen liegen derzeit bei ca ~1MB/s, die nichtbetroffenen Routen bei ~2MB/s.
=== BGP - aller Upstream von FFML des1/c1024/corny nach Berlin ===
Das ffml wiki hat bzgl BGP vmtl. ein Schreibfehler:
„Das BGP Pref (bgp_local_pref) 200 ist der Standardwert und muss nicht explizit angegeben werden. Wenn ein Eintrag 201 gesetzt bekommt, dann hat der andere (ohne Eintrag) Vorrang.“
Die BGP Implementation in Bird präferiert immer die Route mit der höchsten local_pref und damit Berlin.
=== paket loss gw-c1204 und gw-des1 FFML===
Zwischen Node ↔ Gateway kommt es zu packet loss, das Problem liegt vmtl. an den gateways. gw-c1024 ist meistens stärker betroffen wie gw-des1.
=== ipv6 routing gateway FFML ↔ Backbone FFRL ===
Evtl. kommt noch ein ipv6 routing Problem dazu. gw-des1 hat die Adressen 2a01:4f8:162:10d2::a0 und 2a03:2260:115:7600::2
@MPW Wie sieht die Situation aus Deiner Sicht aus? Anhand der Posts kriegt man nicht sauber getrennt was nun letztlich auf unserer Infrastruktur Probleme bereitet und was eventuell schon davor.
Der war seit August 2023 hier nicht mehr aktiv lt. Discourse — auch die sonstigen Mitglieder von @MuensterlandINTERN scheinen in diesem Forum nicht mehr aktiv zu sein?
Ich hab die local_pref grad aus allen Gateways entfernt. Ich bin mir nicht mehr ganz sicher warum wir das seiner zeit gemacht hatten… Mögl. weise ne Altlast.
Unsere Gateways haben, sofern sie Tunnel zum FFRL haben, Tunnel zu allen Standorten die auch alle Aktiv sind. Wir haben halt nur Einfluss darauf wo der Traffic raus geht. Worüber er zurück kommt kann nur der FFRL beeinflussen bzw. vermutlich hängt es auch davon ab aus welchem V4 Subnet die FFRL NAT IP stammt. Wir haben Adressen aus 185.66.193 (DUS) und 185.66.195 (BER) das ist aber nur eine Mutmaßung…
Das stimmt. Ist ein Schreibfehler. Allgemein sind die Infos zu unseren Servern die im Wiki stehen nicht wirklich auf Stand.
Ich hab grad mal längere zeit Pings gegen die drei laufen lassen. Aktuell kann ich nur zu c1024 loss feststellen. Liegt vermutlich daran das die Kiste dezent überlastet ist. Ich hab grad mal ein paar Knoten geschubst, das wird es zwar besser machen aber nur Kurzfristig. Wir arbeiten daran das um zu verteilen aber auf die schnelle kann ich das grad nicht ändern.
Nö. Wenn du aus dem FF Netz zu des1.servers.freifunk-muensterland.de (AAAA Record auf Hetzner IP 2a01:4f8:162:10d2::a0) willst dann verlässt du logischerweise das FF Netz. Ein mtr auf die Interne FF IP (2a03:2260:115:7600::2) wird auch intern geroutet.
aus Sicht der User experience ist alles wieder top. Kein Paketloss, genug Bandbreite. Danke an @corny456
Im Moment geht aller Traffic des gw_des1 via Frankfurt (grafana). Ob es also am Tunnel lag/liegt oder daran das die Gateways durch den reboot jetzt weniger Last haben, wird sich vermutlich erst in ein paar Tagen zeigen.
Von meinem node aus finde ich auch keine Routen mehr von FFRL direkt zum C-IX, es geht alles in den Transit: