[Berlin-wireless] IPv6 Blackholes und LinkQualityMult

[Bastian]

Hallo Liste,

der BBB-IPv6-Ring steht, Uplink an zwei BBB-Standorten in die IPv6-Welt
tut nun auch und wir hängen mit v6-Google und v6-Akamai an einem Switch.
Traumhaft!
Im Backbone haben wir größtenteils den auto-ipv6 cronjob deaktiviert und
statisch Netze aus unserem IPv6-Block vergeben. Traceroutes sehen nun
auch toll aus.

Was passiert aber nun, wenn ein neuer Node mit dem Backbone verbindet
und ein Internet-HNA6 ohne passendes Prefix-HNA6 verkündet? Ob über
diesen Knoten IPv6-Internet überhaupt funktioniert lässt sich doch ohne
passende Absender-IP6 gar nicht feststellen. Selbst mit passendem Prefix
wären unsere Backbone-Nodes offline wegen fehlender auto-ipv6-cronjob-magic.
Praktisch gesehen ist es doch jetzt noch einfacher das (IPv6-)Internet
im Mesh kaputt zu machen, da zu einer fehlerhaften Router-Einstellung
auch noch ein fehlendes Prefix-HNA6 oder deaktiverter auto-ipv6-cronjob
zu Blackholes führen.

Was machen wir gegen Blackholes? User anschreiben und auf Besserung
hoffen. In der Zwischenzeit können wir im Backbone einen Link-Quality
Multiplikator für dieses Blackhole setzten.

Beim Setzen von "option LinkQualityMult '<ipv6-nachbar>
<wert-kleiner-null>'" in /etc/config/olsrd in der Interface-Section zum
Interface mit dem Blackhole-Nachbarn kommt der OLSRd für *IPv4* nicht
mehr noch!

Frage in die Runde: Gibt es eine spezielle Syntax für LinkQualityMult
bei IPv6, müssen wir die olsrd-conf in getrennte Files für v4 und v6
splitten oder gibt es evtl. noch einen anderen Trick um oben
beschriebenes Problem mit einem Blackhole zu lösen?

Ich konnte mir jedenfalls gerade nur damit helfen den OLSRd für IPv6
gänzlich abzuschalten...

Gruß
Bastian

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 538 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140602/e16b71d5/attachment.pgp>