[Admin] Einzelne Webseite aus FFNW Netz nicht erreichbar -bosselligen.de

Moin zusammen,

ich habe die Meldung erhalten, dass bosselligen.de nicht aus dem FFNW Netz erreichbar ist. Gemeldete Hood Wittmund, tritt aber bei meinem Test auf in Hood Friesland auf. Traceroute (109.237.134.44) knallt bei mir direkt auf die Fresse. Kann das einer mal angucken? Habe leider aktuell keinen PC zur Hand.

Beim Test ist mit auch aufgefallen, dass aus dem Apple AppStore keine Downloads durch gingen. Musste erst ins Private wechseln um ein Tool für traces zu laden.

Gruß Jens

Moin Jens,

aus unserem Netz geht das Ganze raus:

traceroute to bosselligen.de (109.237.134.44), 30 hops max, 60 byte packets
1 45.154.109.1 (45.154.109.1) 0.095 ms 0.120 ms 0.077 ms
2 ae0-2002.cr10.dus01.lwlcom.net (185.1.155.45) 0.483 ms 0.499 ms 0.495 ms
3 ae2-100.cr10.fra01.lwlcom.net (185.146.230.67) 3.421 ms 3.289 ms 3.252 ms
4 ae10-1.fra30.core-backbone.com (80.81.195.147) 3.573 ms 3.531 ms 3.483 ms
5 ae2-2029.fra10.core-backbone.com (81.95.15.69) 3.963 ms 3.760 ms 3.623 ms
6 core-backbone.enviatel.de (5.56.19.26) 4.420 ms 4.459 ms 4.326 ms
7 be11-rb2-fra7.envia-tel.net (77.235.191.185) 4.675 ms 4.843 ms 4.829 ms
8 be12-rb2-dcl.envia-tel.net (77.235.191.177) 12.806 ms 12.714 ms 12.815 ms
9 rb2-dcl.dr2.dcl.lej.de.net.cloudpit.io (80.243.51.202) 12.387 ms rb2-dcl.dr1.dcl.lej.de.net.cloudpit.io (80.243.51.210) 14.396 ms 14.283 ms
10 BSR1.DCL.LEJ.DE.NET.CLOUDPIT.IO (194.145.226.22) 14.222 ms BSR1.DCL.LEJ.DE.NET.CLOUDPIT.IO (194.145.226.18) 12.588 ms 12.565 ms
11 * * *
12 * * *

Vom Gateway kann ich mir deren index file laden:

wget bosselligen.de --bind-address=10.18.136.0 :frowning:
URL transformed to HTTPS due to an HSTS policy
–2021-12-10 14:42:56-- https://bosselligen.de/
Auflösen des Hostnamens bosselligen.de (bosselligen.de)… 109.237.134.44
Verbindungsaufbau zu bosselligen.de (bosselligen.de)|109.237.134.44|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »index.html.1« gespeichert.

index.html.1 [ <=> ] 12,31K --.-KB/s in 0,01s

2021-12-10 14:42:57 (912 KB/s) - »index.html.1« gespeichert [12609]

Fehler gefunden, habe NULL IPv4 hier.

Fehler gefunden, IPv4 ist futsch

Moin zusammen,

kann sich bitte einmal einer anschauen warum in mehreren Hoods IPv4 tot ist? Leider haben noch nicht alle Webdienste IPv6….

Gruß Jens

In der Oldenburger hood merke ich ebenfalls probleme mit der addressvergabe. Die adressvergabe dauert solangt das mein Handy eine meldung raus gibt das diese netz keine internetverbindung hat. Ich hab es mit einen zweiten handy ebenfalls gebrüft same result. Nach der meldung kommt dann irgendwann ne connected message. vermutlich nachdem die v4 vergeben wurde.

LG
tarek

In Friesland ist die DHCP Config kaputt:

Dec 22 09:55:00 fri01 bird6: ibgp-gw01.ffcux.net: Socket error: bind: Cannot assign requested address
Dec 22 09:55:00 fri01 node[12408]: { Error: getaddrinfo ENOTFOUND ff02::1%bat-lkfri
Dec 22 09:55:00 fri01 node[12408]: at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:56:26)
Dec 22 09:55:00 fri01 node[12408]: errno: 'ENOTFOUND',
Dec 22 09:55:00 fri01 node[12408]: code: 'ENOTFOUND',
Dec 22 09:55:00 fri01 node[12408]: syscall: 'getaddrinfo',
Dec 22 09:55:00 fri01 node[12408]: hostname: 'ff02::1%bat-lkfri' }
Dec 22 09:55:00 fri01 node[12408]: { Error: getaddrinfo ENOTFOUND ff02::1%bat-whv
Dec 22 09:55:00 fri01 node[12408]: at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:56:26)
Dec 22 09:55:00 fri01 node[12408]: errno: 'ENOTFOUND',
Dec 22 09:55:00 fri01 node[12408]: code: 'ENOTFOUND',
Dec 22 09:55:00 fri01 node[12408]: syscall: 'getaddrinfo',
Dec 22 09:55:00 fri01 node[12408]: hostname: 'ff02::1%bat-whv' }
Dec 22 09:55:00 fri01 node[12408]: { Error: getaddrinfo ENOTFOUND ff02::1%bat-lkfri
Dec 22 09:55:00 fri01 node[12408]: at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:56:26)
Dec 22 09:55:00 fri01 node[12408]: errno: 'ENOTFOUND',
Dec 22 09:55:00 fri01 node[12408]: code: 'ENOTFOUND',
Dec 22 09:55:00 fri01 node[12408]: syscall: 'getaddrinfo',
Dec 22 09:55:00 fri01 node[12408]: hostname: 'ff02::1%bat-lkfri' }
Dec 22 09:55:00 fri01 node[12408]: { Error: getaddrinfo ENOTFOUND ff02::1%bat-whv
Dec 22 09:55:00 fri01 node[12408]: at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:56:26)
Dec 22 09:55:00 fri01 node[12408]: errno: 'ENOTFOUND',
Dec 22 09:55:00 fri01 node[12408]: code: 'ENOTFOUND',
Dec 22 09:55:00 fri01 node[12408]: syscall: 'getaddrinfo',
Dec 22 09:55:00 fri01 node[12408]: hostname: 'ff02::1%bat-whv' }
Dec 22 09:55:01 fri01 bird6: ibgp-ol01.sn.ffnw.de: Socket error: bind: Cannot assign requested address
Dec 22 09:55:01 fri01 bird6: Netlink: Invalid argument
Dec 22 09:55:01 fri01 bird6: ...

jo, anscheinend sind die supernode

fri01.sn.ffnw.de
ol01.sn.ffnw.de
lk-vec01.sn.ffnw.de

betroffen. zumindest taucht dort überall der String GetAddrInfoReqWrap.onlookup in der /var/log/daemon.log auf. Jetzt ist die Frage, was haben diese Supernode gemeinsam und was unterscheidet sie von denen ohne den Fehler.

zwei Sachen sind mir bis jetzt aufgefallen:

die range bzw. option routers in der /etc/dhcp/dhcpd.pools: eigentlich ist das überall:
range 10.18.foo.2 10.18.foo.254
optiopn routers 10.18.foo.1

nur bei fri01.sn.ffnw.de steht:

grep -E 'r(ange|outers)' /etc/dhcp/dhcpd.pools
     range 10.72.40.1 10.72.47.254;
   option routers 10.72.40.0;
     range 10.18.232.1 10.18.239.254;
   option routers 10.18.232.0;
     range 10.18.136.1 10.18.143.254;
   option routers 10.18.136.0;

also der pool immer von 1 anstatt 2 bis 254 und routers 0 statt 1.

das würde allerdings nur die Probleme in dne domains fri01, fri02 und whv "erklären". Das nächste was mir auffiel, sind die Name der batman-Interface. in den logs auf den betroffenen supernode tauchen folgende auf:

ff02::1%bat-lkfri
ff02::1%bat-lohne
ff02::1%bat-ol2
ff02::1%bat-rastede
ff02::1%bat-stadtol
ff02::1%bat-vechta
ff02::1%bat-whv

und folgende stehen in der /etc/dhcp/dhcpd.pools:

   interface bat-lkjadingen;
   interface bat-lkermarsch;
   interface bat-lkbentheim;
   interface bat-lkppenburg;
   interface bat-lkenbueren;
   interface bat-lkteinfurt;
   interface bat-lkjadingen;
   interface bat-lkermarsch;
   interface bat-lkbentheim;
   interface bat-lkppenburg;
   interface bat-lkenbueren;
   interface bat-lkteinfurt;
   interface bat-suedost;
   interface bat-lkems01;
   interface bat-tossens;
   interface bat-lkol01;
   interface bat-bre01;
   interface bat-default;
   interface bat-fri02; <= anders als im log
   interface bat-whv01; <= anders als im log
   interface bat-fri01; <= anders als im log
   interface bat-aurich;
   interface bat-leer;
   interface bat-stadtos;
   interface bat-stadtos2;
   interface bat-vec01; <= anders als im log
   interface bat-ras01; <= anders als im log
   interface bat-loh01; <= anders als im log
   interface bat-ol02; <= anders als im log
   interface bat-ol01;
   interface bat-badiburg;
   interface bat-ossued;
   interface bat-wtm;

vielleicht kann ja jemand hiermit was anfangen ...

LG & schöne Weihnachten trotz der allgemeinen Lage, hoffe euch und euren liebsten gehts soweit gut
Lorenz

diese ganzen node-Fehlermeldung kamen übgrigens von einer dort noch laufenden hopglassinstanz. habe die mal gestoppt, weil tut ja nicht not, dass die läuft, oder?

Korrekt. Läuft alles über yanic.

ok, vergesst einfach was ich mir da bzgl der Interfacenamen zusammengereimt hatte. das lag alles an irgendwelchen alten hopglass-configs. der hopglass-server wurde nun auf allen supernodes gestoppt und disabled.

Die Ursache für die uneinheitlichen ipv4 pools konnte ich jetzt auf die /etc/hood.conf zurückführen, daher meine Frage an Simon: soll das so?

suedwest_V4="10.18.80.0/21"
fri01_V4="10.18.136.0/21"
whv01_V4="10.18.232.0/21"
fri02_V4="10.72.40.0/21"

habe da einmal mit pssh durch die ganzen /etc/hood.conf durchgegrept. bis auf diese 4 Zeilen ist dort überall *.*.*.1/21 anstatt *.*.*.0/21 eingetragen.

LG Lorenz

Kannst Note schon ein Fehler gefunden werden? Bei mir stapeln sich Anfragen, geht seit knapp einem Monat nicht wirklich. Habe weiterhin kein funktionierendes IPv4.

Gruß Jens