[Berlin-wireless] Batman, die Tunnels und das Policy Routing

[Sven-Ola Tuecke]

Hi Marco,

nette Idee. Aber ich denke es verstoesst gegen KISS. Das eigentliche Problem 
mit den NAT-Gateways wird sowas eher verkomplizieren. Gatewayschalten == 
Verbindungsabbruch. Eine zusaetzliche Schaltinstanz mehr == mehr 
Verbindunsabbrueche. Dann doch lieber so ein Tunnelhack wie in Batman. 
IPIP/OpenVpn/Tinc-Tunnels kann man auch manuell aufsetzen, Abstimmung mit den 
Gatewaybetreiber vorausgesetzt.

// Sven-Ola

Am Samstag, 19. Mai 2007 16:17 schrieb Marco Tidow:
> On Sat, May.19. 06:33 +0200, Sven-Ola Tuecke wrote:
> > Hey,
> >
> > damit ist wohl erwiesen, dass selbst wueste Tunnels immerhin etwas laufen
> > :) Ich hab' auch noch einen. Da ist seit ewigen Zeiten ein
> > Kernel-2.6-Feature in der Freifunkfirmware drin (was mich ueberrascht
> > hat):
> >
> > CONFIG_IP_ROUTE_MULTIPATH:
> > Bin am ueberlegen, das komplett auszubauen. Wg. "Non-deterministic".
> > Gegenstimmen?
>
> moin,
>
> CONFIG_IP_ROUTE_MULTIPATH gehört wohl in den Kontext
> Linux-Virtual-Services(LVS).
>
> erwähnt u.a. hier:
>   http://www.ssi.bg/~ja/nano.txt
>     s. "equal cost multi path"
>
>
> weil der olsrd immer den nächsten gateway wählt, nicht den "günstigsten",
> schnellsten + gut erreichbaren,
> hatte ich vor zeiten den gedanken, unterschiedliche HNA´s für verschieden
> schnelle inet-uplinks zu announcen, anstelle von "0.0.0.0":
>
> gateway  : announced HNA
>
>  dummy   : 104.255.255.254   marked "dead", not functional
>   1 Mbit : 104.255.255.253
>   2 Mbit : 104.255.255.252
>   3 Mbit : 104.255.255.251
>   4 Mbit : 104.255.255.250
>   6 Mbit : 104.255.255.249
>   ...
>
> und anstelle eine default-route dynamisch zu setzen, mehrere statische,
> in Reihenfolge abnehmender Bandbreite der gateways gewichtet.  der olsrd
> setzt dann anstelle dessen host-routen auf 104.255.255.249 usw. nach
> aktueller Verfügbarkeit:
>
>   ip route del default
>   ip route add default scope global \
>     nexthop via 104.255.255.254 dev eth2 weight 1 \
>     nexthop via 104.255.255.249 dev eth2 weight 5 \
>     nexthop via 104.255.255.250 dev eth2 weight 4 \
>     nexthop via 104.255.255.251 dev eth2 weight 3 \
>     nexthop via 104.255.255.252 dev eth2 weight 2 \
>     nexthop via 104.255.255.253 dev eth2 weight 1
>   ip route flush cache
>
>
> sieht dann so aus:
>
> root at dm7south:~# ip route ls
> [...]
> 104.136.12.24/29 dev vlan1  proto kernel  scope link  src 104.136.12.27
> 192.168.200.0/27 dev br0  proto kernel  scope link  src 192.168.200.7
> 104.0.0.0/8 dev eth2  proto kernel  scope link  src 104.136.12.7
> default
>         nexthop via 104.255.255.254  dev eth2 weight 1 dead
>         nexthop via 104.255.255.249  dev eth2 weight 5
>         nexthop via 104.255.255.250  dev eth2 weight 4
>         nexthop via 104.255.255.251  dev eth2 weight 3
>         nexthop via 104.255.255.252  dev eth2 weight 2
>         nexthop via 104.255.255.253  dev eth2 weight 1
>
>
> die erste nexthop-route wird immer als "dead" markiert, ist fake
>
> probiert mit zwei uplinks hat´s bislang immer den ersten funktionierenden
> ausgesucht.
>
>   caveats:
>
>     "routes to often-used sites will always be over the same " ...gateway
>       due to caching
>       http://lartc.org/howto/lartc.rpdb.multiple-links.html
>
>
>
> ...nur fehlte bislang die Test-Umgebung mit mehreren (funktionierenden)
> DSL-gateways mit stabilen wifi-setups.
>
>
>
>
> docs dazu:
>
>   http://lartc.org/howto/lartc.rpdb.multiple-links.html
>   http://www.ssi.bg/~ja/#routes
>   http://www.ssi.bg/~ja/nano.txt
>   http://www.ssi.bg/~ja/LVS.txt
>
>
> Gruß, marco
>
> _______________________________________________
> Berlin mailing list
> Berlin at olsrexperiment.de
> http://lists.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin