[Freifunk-Bonn] ip6 diversa: uplinks / collectd / ULA routing / routing an fastd3

Jan Lühr jan at jluehr.de
Sa Jan 17 12:27:55 CET 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo,


Am 01/15/2015 02:29 PM, schrieb Rougu:
> Hallo,
> 
> zum Teil zu nicht mehr ganz taufrischen Themen (und entschuldigt
> den länglichen Beitrag):

Danke auf jeden Fall! Die Anmerkunge sind gut. Ich versuch' mal zu den
einzelnen Punkten zu Antworten. Zum Teil sind es aber leider auch nur
rückfragen.

> 
> ---------------------------------------------------------------------
>
> 
Erreichbarkeit von collectd
> 
> 
> Ältere Firmware hat collectd.conf mit hostname 
> "collectd.kbu.freifunk.net" und AAAA-rec zeigt auf eine öffentliche
>  ip6-addr (ein HE 6in4-tunnel, wie's scheint), die aber öffentlich
> nicht erreichbar ist.
> 
> Aktuelle fw hat eine freifunk ULA für collectd:   :-)
> 
> Vorschlag:
> 
> public DNS: collectd.kbu.freifunk.net AAAA 2001:470:780f:1::6  ->
> löschen
> 
> ff-DNS (fdd3:5d16:b5dd::2): collectd.kbu.freifunk.net AAAA
> fdd3:5d16:b5dd:3::6
> 
> Auf diese Weise würden auch Nodes mit alter Firmware bei collectd
> wieder zuverlässiger abliefern können, oder?

Ja. Danke. Hintergrund ist, auch dass wir den collectd-Server zur Zeit
migrieren. Dadurch ist er unter der externen IP nicht mehr erreichbar.
Wir haben ihn gerade "Zwischengeparkt" und werden ihn hoffentlich bald
woanders hin packen können.


> Weiter verbessern (z. B. falls IPv6 an br-wan):
> 
> Wenn IPv6-Resourcen nur innerhalb des Freifunk-Netzes erreichbar
> sind und vom FF-Router erreicht werden müssen, könnte das
> Source-Interface auf br-freifunk gesetzt werden.
> 
> Bei collectd.conf ist das möglich (kleine semantische Variation der
>  bestehenden Einträge)

> Das funktioniert bei mir im Moment, aber weil offentlich die Route
> über das zu verwendende src-if entscheidet, ist die Stabilität
> erstmal fraglich (siehe auch weiter unten).

Danke. Das ist ein sehr guter Punkt.
Was genau meinst Du mit "offentlich"? Offensichtlich, öffentlich oder
hoffentlich?

Kann ich mich denn darauf verlassen, dass nur noch
IPv6-Absenderadressen des Source-Interfaces verwendet werden? Und nur
noch Router die auf dem Source-Interface zur Verfügung stehen?

> 
> Prüfen der Absende-IP (br-wan hat ipv6 uplink, nach neustart von
> collectd)
> 
> ping:
> 
> # tcpdump -i br-freifunk 'icmp6 and ip6[40]=128' 08:50:41.062389
> IP6 2001:67c:20a0:b107:b248:7aff:febe:d4fa > fdd3:5d16:b5dd:3::6:
> ICMP6, echo request, seq 9, length 64
> 
> und Daten abliefern:
> 
> # tcpdump -i br-freifunk 'port 25827' 08:56:41.046875 IP6
> 2001:67c:20a0:b107:b248:7aff:febe:d4fa.46786 > 
> fdd3:5d16:b5dd:3::6.25827: UDP, length 873
> 
> qed.

Wobei mir erstmal nicht klar ist, ob das jetzt Zufall ist (zufällige
Adresswahl) oder Absicht.

> 
> 
> 
> ---------------------------------------------------------------------
>
> 
IPv6-Uplinks
> 
> Das interne ff-routing für ip6 bricht, wenn if br-wan default-Route
> für ip6 hat und diese an erster Stelle der ip6-default-Routen
> steht.
> 
> Soweit klar.
> 
> 
> a) wg möglicher Routen/Src-Addr-Konflikte ipv6 auf br-wan
> abschalten?
> 
> Der vorgeschlagene Workaround 
> (https://github.com/ff-kbu/fff/commit/9cfe567771a5ddaabf84a345a207399a1d594f17#diff-64e2d6ea7bb6f6c907fd641221ea303d)
>  ist IMHO ohne Wirkung:
> 

> sysctl wird in rc.d mit S11 gestartet, also noch vor networking. 
> "net.ipv6.conf.br-wan.disable_ipv6=1" greift da noch nicht.
> 
> Statt dessen hilft:

Danke für die Info. Bauen wir ein.


> 
> b) ipv6-Uplink doch nutzen?
> 
> *** Wenn IPv6 an br-wan nicht abgeschaltet sondern genutzt würde,
> wären die FF-Router konsistent für IPv4 und IPv6 konfiguriert: der
> direkte Uplink wird für Zugriffe des FF-Routers auf das öffentliche
> Internet genutzt. *** Das ist wohl schon länger Konsens.

Variante b) Steht für das kommende Firmware-Release auf der Agenda.
Mein Zug erreicht gleich Köln Hbf, s.d. mir jetzt die Zeit fehlt viel
zu schreiben.
Ich komme auf jeden Fall nochmal auf Deine Ideen zurück, wenn wir an
2.0 schrauben.

> Problem im IPv6-Routing?
> 
> 
> Für ip6 kommt von jedem Supernode eine default route:
> 
> default via fe80::fc89:77ff:fe72:bd9d dev br-freifunk default via
> fe80::1891:a2ff:fe61:febb dev br-freifunk default via
> fe80::c434:84ff:fe23:46d5 dev br-freifunk default via
> fe80::cb3:b4ff:fe70:aec4 dev br-freifunk default via
> fe80::88cd:84ff:feb4:33bc dev br-freifunk default via
> fe80::905b:d1ff:fe31:b00a dev br-freifunk
> 
> *** Beliebige IPv6-Ziele sind NICHT erreichbar, wenn 
> fe80::fc89:77ff:fe72:bd9d das tatsächlich genutzte default-gw ist,
> also mit src addr aus 2001:67c:20a0:b101::/64 geroutet wird. ***

@gevatter: Das wäre Deiner - bitte check'n.



> Frage: - Was ist bei 2001:67c:20a0:b104::1 (fastd3?) los?

b104 ist eigentlich fastd (hint: letztes Byte in der Netz-ID
beachten). Der Host ist morgen weg.

> findet man in ruhigen ff-Zeiten gefühlte 20-40 % Anteil an ICMP6 
> neighbor solicitations:

Oh - ja. Wir haben zu viele Prefixes. Schwieriges Thema.
Jetzt ist der Zug da. :-)

Cu



- -- 
There's a ripped off cord
To my TV screen
With a note saying:
"Im not afraid to dream"
- -- Donkey Boy, Crazy Something Normal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJUukc7AAoJEBbh0SAKTJyuwP0P/03jf4szMQPRGVLvFri3r7UK
7qdsCO6NMfHgSEgNcae45fheYUwRNLToBYz/pSPYpl49/7DUEW8Bi9w2A5Qi+03I
WNtOsuLy3sF2tode8T9B0k9r7aRdXUMqzx/oIrqSI2gBzb92R/uY7IVtIQCAgMQg
iLFaWXN1kSObj8mcwK0gEkJh1ILyYwMdqNcrufEDxovaiojJ0DUphFJ4QxEKfzuV
0VNvWfcfGKShRwYC2srKEbZxcPQcutV5S+SLSia5Tw/0Q65wUB3JGGlIgfonzlBY
5BOcfFB1u4T4Xxl/DoqsafsFyDI9haFfbL9iI9pa6bDWaJ42BT6uPnJlKKUawmC9
IOnAXKBlWwsC4HMytFAnScGwNUqm/P5IICPiu+OHs0eFWDZP5DFo5jxyZybo2jaE
TVt0drcbdEP6cvDi0dk8+5naJR3zjlhkVrHg42IcMGV+5nf1eoHatewgCkHyXCi/
gaRK87hAwgRJVoz3W3xVCb3RYK6AY2gZWZgym/HMa8MBxGcmRZrIE1qIHGwFrZjr
aklAa5HGcRKdGxy1zl8SxUr2fRu5aVbJ7C9fylI2oTw9B5ntsjsF3vqe+fvLgWkD
kIh7ZhPwnN8BogDizbX0d3s3ehz1zRjngwTWn255vaiQliZhS2JlN7HK6bpwQhH+
L02MhWW+0qTq6iZFieT6
=BAum
-----END PGP SIGNATURE-----



Mehr Informationen über die Mailingliste Freifunk-Bonn