SvenOlaTuecke-Mail2007jul18-dyngw und cron.minutely iproute2

Aus Weimarnetz Wiki
Zur Navigation springen Zur Suche springen

Mail1

Die Default-Route in Table 254 (Iproute2-speak: Table main) wird ja wie
immer mit "route -n" bzw. "ip r" angezeigt. Diese Tabelle ist fuer alle.
Kann mit den alten "iffonfig" und "route" Befehlen verwaltet werden . Da
irgendwie jeder die Befehlsfolge fuer "route add default gw a.b.c.d" bzw.
"ip r add default via a.b.c.d" kennt und die Default-Route eine
"Gemeinschafts-Ressource" ist, hab' ich das dyngwplain und das
Policy-Routing eingefuehrt.
 
Folgende Aussagen gelten fuer die Freifunk-Firmware, was Selberbastler alles
so treiben steht auf einem anderem Blatt - manche koennen's - manche eben
nicht.
 
* Das dyngwplain announced HNA 0/0, sobald eine Default-Route in Tablle 254
mit Metrik 0 vorhanden ist. Genau dieser Zusammenhang. Sonst kein anderer.
Darum "plain"..
 
* Nebenbei gibt's einen Cron-Job /usr/sbin/cron.minutely, der prueft mit
"traceroute", ob die manuell gesetzte Default-Route ueberhaupt funktioniert.
Falls nicht -> Default-Route weg -> kein HNA 0/0 -> anderes Gateway -> alle
Gluecklich. Der Test dauert Minuten. Dafuer kann man Traceroute nicht so
einfach "besch**ssen".
 
* Damit ein Node mit traceroute selber weiter testen kann, ob die vormals
kaputte Default-Route evnt. wieder hochkommt, wird diese im Fehlerfall in
eine Hintergrund-Default-Route gewandelt, die *nur fuer das Geraet selbst*
gilt. Guckt man mit "ip rule ls" nach Regeln. Die Routen kann man uebrigens
mit "ip ro ls table 252" anzeigen.
 
* Jetzt gab's oefter den Fall "Mein Gateway nur fuer mich, will aber
trotzdem Freifunken aber die anderen nicht nerven". Darum hab' ich an die
Deaktivierung des dyngwplain ein erweitertes Policy-Routing geklemmt. Kein
dyngwplain -> alle OLSR-Routen (inkl. der OLSR-Default-Route gueltig fuer
alle anderen) in Tabelle 111. Das dyngwplain wieder aktivieren -> alles wie
vorher in Tabelle 254 ("main").
 
* Die Tabellen-Nummern stehen in /etc/iproute2/rt_tables. 111 == olsr, 254
== main, 252 == dyngw.
 
* Das kann man alles auskommenterien. Beliebt bei Leuten, die als
Internet-Zugang einen "UDP-ist-bei-mir-nicht" Firewall haben und/oder
einfach die Konfig nicht im Griff. Aber im Regelfall hilft es, schwarze
Loecher (aka nicht-funktionierende Internet-Zugaenge) zu vermeiden. Ein
Gateway ohne UDP ist eine Krankheit IMO - kann man gleich einen Zwangsproxy
machen.
 
* Ach und wer schon immer neugierig war: "ip ro ls table local" ist noch
interessant. Das sind die durch IP/Netzmaske direkt den Interfaces
zugeordneten "internen Routing-Eintraege" mit absoluter Prio.
 
Weiter gehts unter "LARTC" (-> google).
 
HTH,
// Sven-Ola

Mail2

a. Das soll so sein. Ich soillte es wirklich in den OLSR einbauen - dann muss man selbst kompileren um es auszuschalten. Aber ich werde besser den Schalter umbenennen. "ff_dyngw" -> "ff_policyrt" oder so. Dann ist es evnt einfacher.
 
Du verlaesst dich auf die Antzeige von "ip ls" - die zeigt aber nur die "Main" table. Guck' mal in die Web-UI unter "Status". Da sind alle Routen angezeigt. Und es funktoniert, mach doch mal Traceroute oder ping google.de
 
Noch'n Nachsatz. Was tatsaechlich noch fehlt ist eine zusaetzliche Default-Route in der Tabelle "Default". Die ist im Moment noch leer. Warum? Wenn man Policy Ruoting aktiviert, und eben *keine* manuelle Route setzt. Dann soll's ja sicher wieder ueber Freifunk gehen. Funktion waere etwa so:
 
Anderer Freifunk-Benutzer :
 Genrell Inet via table olsr (111)
 
Selber
 Inet via table main falls manuelle defaultroute
 Falls keine manuelle defaultroute, dann Inet via table default
 
Die Table "default" ist im Moment leer. Wird per default *nach* main abgearbeitet. Wenn eine Table keine Default-Route hat gibt es eine implizte "Throw-Route" --> naechste Rule -> naechste Table.