Die sozial.asozial pfSense im space schickt traffic an die Jade VM am acraze, die hat dann wireguard tunnel zu allen meinen routern und macht dynamic routing mit babel.
Zusätzlich zu den BGP fähigen VMs gibts auch noch einen reinen relay router der direktes peering mit Magenta hat und die latenzen meißt etwas verbessert oder anderst gesagt einfach eine abkürzung bei der üblichen peak time congestion bietet:
Sollte sich jemand für IPv6 und/oder BGP interessieren wir haben ja /44 an address space, d.h. wir könnten noch 15x /48 an mitglieder weiterdelegieren zum selber announcen und damit spielen oder kleinere prefixe die direkt zu meinen routern gehn, davon haben wir “genug für alle zeit”. Geb da auch gern ne BGB/babel oder generell routing einleitung.
pfsense reverse path filtering verhalten checken.
Upstream interfaces sollten “loose” (i.e. irgendne reverse route existiert) und LAN interfaces sollten “strict” (i.e. reverse route zeigt auf das incoming interface) verwenden. Siehe RFC3704. Obwohl wireguard das mit AllowedIPs auf der upstream router seite eigendlich auch macht.
MTU im RA richtig einstellen (1420) um PMTU blackholes vorzubeugen Done. Note: pfSense lasst einen die MTU nicht nur für die IPv6 RA messages einstellen. Die MTU ist jetzt für v4 auch auf 1420 begrenzt…
Update: wir sind jetzt wieder multihomed. Der zweite wg tunnel ist jetzt wieder up. Die MTU habe ich auch auf 1420 gesetzt aber mit dem caveat dass es wegen einem pfSense problem nun v4 auch betrifft obwohl das eigendlich nicht notwendig wäre.
Update: hab jetzt BFD (bidirectional forwarding detection) für die wg tunnel implementiert, so dass einkommender traffic automatisch umgeroutet wird sollte ein tunnel brechen. Babel sessions mitm sozial wäre mir zwar lieber aber das kann ja der pfsense semmel wieder ned.
Der trick war hier im BIRD auf meiner seite eine static route zu machen die nur im kernel eingetragen wird wenn die bfd session zum gateway up is:
protocol static static2 {
ipv6;
# Only install these routes if the gateway is bfd reachable. babel
# will then redistribute these to the other routers. The babel
# routes have lower metric than this bird one so they're only used
# as a fallback.
route 2a0c:9a40:8070::/56 via 2a0c:9a40:8070:1002::52a1 bfd;
}
Lang ausständiges update: Das routing ist jetzt komplett dynamisch mit RFC 8966 (IETF datatracker) aka babel (Juliusz’s website) und nicht mehr (semi)static route mit BFD. Das war damals ein kompromiss um die pfSense zügig an meine router zu spaxen, war aber nie besonders stabil weil bei den uplinks latenz fluktuationen wie sie genre zu den peak zeiten passieren nicht erkannt wurden und dann wird halt alles langsam.
Das einzige verbleibende problem ist jetzt die performanz der upstreams. Dadurch dass es sich da halt immer um günstige hoster handelt ist das, bandbreiten technisch, einfach nicht so trasparent wie einem lieb wäre.
Aus diesem grund gibt es zwei neue ansätze unser IPv6 deployment zu verbessern:
a) Magenta auf native IPv6 modus umschalten, IPv4 CGNAT fürs LAN in kauf nehmen, etwaig benötigte v4 port forwardings richtung lokale server mit ner Hetzner VM abdecken IPv6 ingress zu servern aber weiter über mein AS.
b) Magenta bleibt bei IPv4 native, wir deployen SIIT+NAT64 (aber weiterhin im IPv6+v4 dualstack) und verwenden einen von mir entwickelte erweiterung (GH commit) von DNS64 um den großteil des traffics (am ende) richtung IPv4 zu lenken aber transportiert wird das über den NAT64.