[Discuss] alternatives NAT Package fuer die freifunkfirmware

Henning Rogge (spam-protected)
Mo Feb 2 19:01:40 CET 2009


On Montag 02 Februar 2009 18:22:06 Harald Geyer wrote:
> > Ich denke, es bricht mit einigen grundlegenden annahmen die meistens
> >
> > bei routing getroffen werden.
> > ( so konzepte wie distinkte link netze, 1 interface == 1 distinkte
> > IP, ...)
>
> Naja, das meiste was wir im Mesh machen bricht Annahmen, die sonst
> wo gemacht werden ... ;)
>
> Außerdem: Das Interface zu addressieren ist eigentlich Aufgabe
> des Layer 2. Der Layer 3 muss davon eigentlich nicht's wissen,
> aber ist natürlich manchmal praktisch.
Nicht unbedingt... die Routing-Table ist dafür zuständig und die wird ja auf 
Basis der IPs der Interfaces erzeugt.

> > Aber man korrigiere mich, vielleicht ists ja sehr einfach.
>
> Also ich hab' solche Setups seit Monaten laufen, ist ansich kein
> Problem, linux schafft das, solang man ein paar Sachen einhält:
>
> a) Wirklich nur gleiche Adresse konfigurieren aber nicht gleiche
> Subnetze (also überall außer auf einem Interface /32) weil arp lookups
> gehen nur bei einem Interface raus - den Rest muss man mit host routen
> machen. Da kommt uns OLSR ja sehr entgegen.
>
> b) Aufpassen, das in einem Ethernetsegment die Zuordnung IP->MAC
> eindeutig ist - eh klar warum ... Also bei WIFI/WAN kein Problem,
> aber bei zwei WIFI Interfaces oder wenn eine Bridge dazu kommt, dann
> sollte man aufpassen, bzw. doch eine IP opfern.
OLSR ist ein Layer-3 Netz... und die verschiedenen Interfaces eines Knoten 
werden direkt von OLSR genutzt... dazu kommt noch das der OLSR Standard unter 
der Prämisse geschrieben wurde das jedes einzelnes Interface eine eigene 
eindeutige IP hat, ansonsten läuft man in Probleme. Diese sind zwar nicht 
immer offensichtlich, aber sie existieren.

> > Allerdings - ich denke, was ihr versucht zu implementieren ist quasi
> > high availability cluster/takeover (*).
>
> Nein, eigentlich nicht. Die Idee ist nur, dass man nicht eine IP/Interface
> sondern eher eine IP/Routing table braucht, eben weil die Interfaces
> halt nicht sebstständig routen (und weil sie eigentlich nicht zum Layer 3
> gehören.)
>
> > Geht sicher. Aber ich vermute, da werden noch ein paar verrenkungen
> > auf euch zukommen.
> > Es wirkt am anfang einfach. Nachher kommt man dann drauf, dass das
> > fuer die "oben" liegenden applikationen gar nicht mehr so einfach wird.
>
> Also solang man sich an das hält, was ich oben beschrieben habe, sind
> keine Verrenkungen notwendig. Für die meisten Applikationen wird die
> Sache dadurch einfacher, weil sie eher die Annahme IP=host als sonst
Du Verwechselst die Interface-IPs mit der Main-IP der Routers. Die IPs der 
Interfaces sind nur für den Routing-Daemon von Belang, die Anwendung muß die 
eigentlich nie wissen.

> irgendwas haben. Einzige Ausnahme, die ich kenne, ist eigentlich der
> OLSRd, aber IMO ist das ein Misfeature des RFC.
OLSR Überträgt in seinen Paketen nur IP-Adressen, weil es eben ein Layer-3 
Protokoll ist. Was zu nicht auflösbaren Mehrdeutigkeiten führt.

Ich würde keinem Empfehlen eine IP mehrfach zu nutzen... und denen die es 
machen würde ich empfehlen es durch eine saubere Konfiguration zu ersetzen, 
damit man nicht irgendwann mal in Schwierigkeiten steckt.

Wenn es technische Gründe gibt warum man eine solche Konfiguration unbedingt 
braucht würde ich sie gerne hören um diese Probleme nach und nach zu 
beseitigen.

Henning





Mehr Informationen über die Mailingliste Discuss