[Berlin-wireless] Tunnel-Technik (hier: Boell-GW)

[Sven-Ola Tuecke]

Hallo (Daniel),

habe mich immer gewundert, warum der OLSR auf der Boell soviel 'rummosert 
(cannot add route / cannot del route). Und etwas gebraucht, es 
herauszufinden. Auf dem Boell-Cube ist folgendes TINC-Iface aktiv:

root at mtx-boell:~# ip a l dev bbb
7: bbb: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc prio qlen 1000
    link/ether 00:ff:a5:60:87:e9 brd ff:ff:ff:ff:ff:ff
    inet 104.0.7.42/8 brd 104.255.255.255 scope global bbb
    inet 105.0.7.42/8 brd 105.255.255.255 scope global bbb:bat

OK - wir haben also mind. zwei Interfaces im 104er mit /8 (es gibt ja noch 
eine Ad-Hoc-Wifi-Karte). Und damit das nicht nervt, ist offenbar folgendes 
konfiguriert:

root at mtx-boell:~# tail -n 2 /etc/tinc/bbb/tinc-up
route del -net 104.0.0.0 netmask 255.0.0.0 dev bbb
route del -net 105.0.0.0 netmask 255.0.0.0 dev bbb

Und hier haben wir den Grund fuer die Mosereien. Der olsrd setzt die 
Hostrouten leider nicht in der gunestigen Reihenfolge. Und braucht daher die 
/8-Netzroute auf dem Interface. Beispiel:

Erster Route-Befehl vom OLSR z.B.:
  ip r add 104.0.0.1 via 104.0.0.2 metric 3
Zweiter Route-Befehl vom OLSR z.B.:
  ip r add 104.0.0.2 via 104.0.7.253 metric 2
Dann erst vom OLSR:
  ip r add 104.0.7.253 dev bbb metric 1

Und schon geht's nicht. Weil's beim ersten Route-Befehl ja noch keine 
104.0.0.2 Hostroute da ist. Der Cube ARPt, findet nix und daher gehen viele 
Routen als Fehlermeldungen unter. Man koennte im OLSR-Daemon solche 
Sitzuationen abfangen bzw. den Routen-Baum vorsortieren. Kostet aber 
(Rechen|Programmier)-Zeit. Meine Empfehlung: Engere Netzmaske fuer das 
Tinc-Tunneldev. /24 beispielsweise. Soviele Tinc-Endpunkte kann's ja auch 
nicht geben. Und vor allen Dingen die Iface-Netzroute leben lassen.

// Sven-Ola