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

Do Jan 15 14:29:47 CET 2015

Hallo,

zum Teil zu nicht mehr ganz taufrischen Themen (und entschuldigt den 
länglichen Beitrag):

---------------------------------------------------------------------
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?

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)

LoadPlugin ping
<Plugin ping>
         TTL 127
         Interval 30
         Device "br-freifunk"
         Host "fdd3:5d16:b5dd:3::6"
</Plugin>

LoadPlugin network
<Plugin network>
         Forward false
         <Server "fdd3:5d16:b5dd:3::6" "25827">
                 Interface "br-freifunk"
         </Server>
</Plugin>

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).

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.

---------------------------------------------------------------------
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:

/etc/rc.local

# echo 0

# No IPv6 on uplink
echo "1" > /proc/sys/net/ipv6/conf/br-wan/disable_ipv6

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.

Ein paar Überlegungen zur möglichen Nutzung vorhandener ip4+ip6-Uplinks:

Konkreter Fall: Uplink mit
- ip4, mit Netcologne-Multikabel als Gateway -> public ip4-Internet,
- ip6, mit HurricaneElectric 6in4-Tunnel -> public ip6-Internet.

Zugriffe via def rt laufen über br-wan.

Erreichbar wären trotzdem alle direkt verbundenen ip6-Netze 
2001:67c:20a0:b10X::/64, weil die

Zusätzlich erreichbar muss das ff-ULA-Netz (/48 !) sein, also 
behelfsweise über zwei Supernodes zwingen (primär und fallback):

/etc/config/network

config route6
         option interface 'freifunk'
         option target 'fdd3:5d16:b5dd::/48'
         option gateway 'fe80::c434:84ff:fe23:46d5'
         option metric '1024'

config route6
         option interface 'freifunk'
         option target 'fdd3:5d16:b5dd::/48'
         option gateway 'fe80::905b:d1ff:fe31:b00a'
         option metric '1280'

Damit sollten interne FF-Resourcen korrekt erreicht werden, Zugriffe 
nach aussen, z. B. für fastd via ip6 (irgendwann) aber über br-wan 
laufen. So ist es dann auch (bei mir).

Ausblick:

(ref: http://wiki.openwrt.org/doc/uci/network)
"Since OpenWrt Barrier Breaker, netifd supports IP rule declarations 
which are required to implement policy routing."

Schauen wir also voraus zum nächsten Major Release unserer fw.

Unter anderem wegen: 
https://lists.debian.org/debian-ipv6/2014/11/msg00004.html warte ich 
erstmal ab, was für die zukünftige IPv6-Konfiguration der Supernodes in 
petto ist:

Die Supernodes verteilen jetzt schon Kenntnis zu Routen zu 
fdd3:5d16:b5dd::/64, was aber derzeit anscheinend nicht verwertet werden 
kann.

17:14:36.490258 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 
88) fe80::88cd:84ff:feb4:33bc > ff02::1: [icmp6 sum ok] ICMP6, router 
advertisement, length 88
         hop limit 64, Flags [other stateful], pref medium, router 
lifetime 90s, reachable time 0s, retrans time 0s
           prefix info option (3), length 32 (4): 
2001:67c:20a0:b103::/64, Flags [onlink, auto, router], valid time 
86400s, pref. time 14400s
             0x0000:  40e0 0001 5180 0000 3840 0000 0000 2001
             0x0010:  067c 20a0 b103 0000 0000 0000 0000
           prefix info option (3), length 32 (4): fdd3:5d16:b5dd::/64, 
Flags [router], valid time 86400s, pref. time 14400s
             0x0000:  4020 0001 5180 0000 3840 0000 0000 fdd3
             0x0010:  5d16 b5dd 0000 0000 0000 0000 0000
           mtu option (5), length 8 (1):  1350
             0x0000:  0000 0000 0546

A propos policy routing:

Vielleicht ist es zu schaffen, die dynamisch über br-freifunk 
eintreffenden "prefix info options" in aktive Routingeinträge zu 
übersetzen, die nur für eine Rule "freifunk" gelten und nicht global 
gesetzt werden.

Die globale Routingtabelle des ff-Routers wäre dann per Default nur mit 
Uplink-Routing bestückt.

--------------------------------------------------------------------------
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.
***

Hier bricht die Route am 1. Hop ins öffentliche Netz aus und führt zu 
immer demselben Node bei Hetzner. Das betrifft dann auch alle lokalen 
Clients des jeweiligen Nodes, für die IPv6 dann temporär nicht mehr 
funktioniert.

Beispiel: (hier zu ipv6.google.com [2a00:1450:4005:809::1002])

# traceroute -6 2a00:1450:4005:809::1002
traceroute to 2a00:1450:4005:809::1002 (2a00:1450:4005:809::1002), 30 
hops max, 16 byte packets
  1  2001:67c:20a0:b104::1 (2001:67c:20a0:b104::1)  55.460 ms  25.290 ms 
  24.346 ms
  2  www3.jluehr.de (2a01:4f8:120:7012::2)  47.039 ms  47.300 ms  47.059 ms
  3  www3.jluehr.de (2a01:4f8:120:7012::2)  45.294 ms  46.082 ms  47.855 ms

Mit Hostroute über eines der anderen Default-Gateways/Supernodes (alle 
getestet):

ip route add 2a00:1450:4005:809::1002 via fe80::905b:d1ff:fe31:b00a dev 
br-freifunk

führt der Weg über das Exit-Gateway beim CCC zum Ziel, wie's wohl 
gedacht ist.

# traceroute to 2a00:1450:4005:809::1002 (2a00:1450:4005:809::1002), 30 
hops max, 16 byte packets
  1  2001:67c:20a0:b101::1 (2001:67c:20a0:b101::1)  25.311 ms  24.571 ms 
  24.489 ms
  2  fdd3:5d16:b5dd:3::3 (fdd3:5d16:b5dd:3::3)  48.713 ms  97.352 ms 
97.800 ms
  3  2001:67c:20a0:a::1 (2001:67c:20a0:a::1)  62.362 ms  49.001 ms 
48.166 ms
  4  de-cix20.net.google.com (2001:7f8::3b41:0:2)  65.540 ms  66.050 ms 
  64.980 ms
  5  2001:4860::1:0:70c3 (2001:4860::1:0:70c3)  66.509 ms  136.522 ms 
65.300 ms
  6  2001:4860::8:0:5038 (2001:4860::8:0:5038)  68.060 ms  67.606 ms 
67.296 ms
  7  2001:4860::8:0:67ec (2001:4860::8:0:67ec)  65.025 ms  70.960 ms 
63.523 ms
  8  2001:4860::1:0:fbc (2001:4860::1:0:fbc)  119.497 ms  97.842 ms 
132.885 ms
  9  2001:4860:0:1::6b5 (2001:4860:0:1::6b5)  64.455 ms  79.474 ms 
120.083 ms
10  2a00:1450:4005:809::a (2a00:1450:4005:809::a)  104.579 ms  68.390 ms 
  67.306 ms

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

-------------------------------------------------------------------
Overhead zu nicht erreichbarem Ziel?

mit "tcpdump -i br-freifunk 'icmp6'

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

05:59:36.391601 IP6 fe80::c434:84ff:fe23:46d5 > ff02::1:ff00:4: ICMP6, 
neighbor solicitation, who has 2001:67c:20a0:b100::4, length 32

Konkret: Alle Supernodes fragen ständig nach 2001:67c:20a0:b100::4, 
wobei dieses Ziel aber nicht auffindbar zu sein scheint.

???

-------------------------------------------------------------------
Ergebnis (erstmal für mich):

- ff-Router hat ip4 und ip6 Uplink für Zugriffe aufs öffentliche 
Internet und funktioniert mit ein paar Workarounds.
- collectd wird über erzwungenes Quell-Interface erreicht
- ULA-Netz wird über statische IPv6-Route erreicht: damit funktioniert 
der Zugriff auf IPv6-Freifunk-DNS.

These:
- policy routing ist im Moment nicht nötig um ipv6 am Uplink zu nutzen.

Gruß,
rougu

Am 02.12.14 um 09:11 schrieb Jan Lühr:
> Hallo,
>
> args - das ist ein known-issue. IPv6 Uplinks kann unsere Firmware leider
> (noch - siehe IPv6-Diskussion hier vor einigen Tagen) nicht.
>
> Bis zur Umstellung von collectd ist diese Auswirkung niemandem aufgefallen.
> Bitte wende
> https://github.com/ff-kbu/fff/commit/9cfe567771a5ddaabf84a345a207399a1d594f17#diff-64e2d6ea7bb6f6c907fd641221ea303d
>
> an.
>
> Sorry, Gruß Jan
>
>
> Am 12/01/2014 11:46 PM, schrieb Nunatak:
>> Hi,
>>
>> ein TP-Link 841N mit Firmware 1.2.1b hatte unmittelbar nach der Ergänzung
>> eines eigenen Uplinks plötzlich keine collectd-Statistik geliefert.
>> Fand ich erst nicht soo wichtig, aber
>>
>> # ip -6 route show
>>
>> zeigte dann 6 default-Routen, wobei die erste folgende war:
>>
>> default via fe80::a96:.... dev br-wan metric 1024 expires 0sec
>>
>> Alle nachfolgend aufgeführten ipv6-"default"-Routen liefen wie sonst (bei den
>> von mir betreuten Routern) üblich über dev br-freifunk .
>> Gruß,
>> Nunatak