[Discuss] alternatives NAT Package fuer die freifunkfirmware

[Harald Geyer]

> Es ist beispielsweise nicht möglich in TCs zwischen zwei Links zu
> unterscheiden die zu Nodes gleicher IPs gehen.

Ich wüsste nicht, wozu man in den TCs parallele Links announcen
sollte ... die Topologie ist ja nicht interfacespezifisch.

>  Genau so wenig ist es
> möglich die Hellos dieser beiden Links zu unterscheiden, was zu
> Fehlern in der LQ-Berechnung führen kann.

Hm, ja stimmt das kann sogar passieren, wenn die Links in verschiedenen
broadcast domains liegen. In diesem Fall seh' ich das Problem...
Ich denke der Vorschlag aus einem anderen Mail, das konfigurierbar zu
machen, gefällt mir ganz gut.

> > ... daneben ist das RFC in dieser Hinsicht aber auch nicht ganz eindeutig,
> > weil es im Endeffekt offen lässt, welche Einheit nun ein OLSR-Node ist
> > und welche Interfaces des OLSR-Node nun OLSR-Interfaces sind. Siehe
> > dazu zum Beispiel den Thread der auf
> > http://lists.olsr.org/pipermail/olsr-dev/2008-August/002378.html
> > folgt - insbesondere deine eigenen Kommentare.
> Also die Sache mit den Interfaces ist ganz eindeutig...
> 
> RFC Sektion 1.1:
> OLSR interface
> 
> A network device participating in a MANET running OLSR.  A node
> may have several OLSR interfaces, each interface assigned an
> unique IP address.

Schon, aber worauf ich hinaus wollte ist dass man das RFC auch so
lesen könnte: Die nicht-funk interfaces nehmen ja nicht am MANET
teil (weil am Kabel gibt's ja keine mobility) also gelten die
Einschränkungen des RFC nicht, obwohl das interface natürlich
trotzdem vom olsrd verwaltet wird.

Das RFC hat Interoperabilität als Ziel, aber nachdem die Kabel ja
sowieso fix sind, würd' es schon auch Sinn machen Kabelinterfaces
als "matter of local policy" ohne Beschränkungen stehen zu lassen.

Aber das ist natürlich uninteressante Haarspalterei, ich wollt nur
anmerken, dass das RFC (vermutlich bewusst) sehr abstrakt und 
allgemein geschrieben ist und es bei der Implementation eigentlich
so viel wie möglich offen lässt. - Ist zumindest mein Eindruck
nach dem Vortrag vom Thomas Clausen.

> > Überhaupt finde ich, dass es eines der strukturellen Probleme in
> > unserem Netz ist, dass in den Köpfen vieler Leute
> > olsr router == olsrd instanz <=> irgendein linksys router
> > gilt.
> Ich würde mittelfristig gerne zu einer Lösung kommen das ein Standort
> (evt. mit mehreren verbundenen Linksys-Boxen) sich im Netz wie ein
> einheitlicher OLSR-Knoten verhält, d.h. die Verbindungen per Ethernet
> werden unsichtbar und die X Geräte tuen so als wären sie eine Box mit
> vielen Interfaces (die jedes eine eigene IP drin haben).

Ja, ich denke das wäre sehr wichtig und hätte mehr Verbesserungspotential
als alles, was mit Metriken etc. noch erreichbar ist.

> > Ja, ich weiß: Z.B. dass der tunnelserver MID-Messages ausschickt, wo
> > 40 Mal die selbe IP drinnen steht.
> Was im Falle von MIDs zum Glück zu nicht so vielen direkten Fehlern im
> Code führt. Im Falle von TCs gehen wir beispielsweise von einer
> sortierten Liste aus und ich bin nicht sicher was der Code aktuell mit
> Duplikaten machen würde.

Hm, also TCs werden doch eh nur mit den main IDs verschickt, wo sollen
da Duplikate auftauchen?

 
> > Aber dieses Paket löst nur einen Teil des Problems (nämlich NAT),
> > aber nicht das Problem für den Traffic, der vom Device selbst kommt.
> > (Dazu könnte der olsrd natürlich überall seine Main-IP als src IP
> > eintragen, aber ob das als "sauberes setup" durchgeht ist dann
> > wieder Ansichtssache.)
> Die Main-IP ist sogar eigentlich die einzige IP die dann eine (wenn
> überhaupt) öffentliche IP braucht.

Ja, mit so einem Setup hätte man dann sozusagen link local IPv4 Adressen
erfunden - eigentlich müsste man in diesem Fall die privaten Interface
IPs nicht einmal mit MID Messages announcen, aber das ist dann wirklich
nicht mehr RFC konform ... ;)

> > Kennst du da irgendein Gegenbeispiel an das ich nicht gedacht habe?
> Wie schon in einer anderen Mail erwähnt habe verbaut uns das einige
> Sachen in Hinsicht der Linkmetriken die ich momentan teste.

Hm, das klingt interessant. Allerdings hab' ich dieses Mail anscheinend
nicht gekriegt ... Link ins Archiv?
 
> > a) $lieblingswebsite vergisst mich, wenn sich meine IP ändert
> Wieso sollte sich deine IP ändern wenn du öffentliche IPs hast ?

Weil, wenn es in der Route nicht explizit überschrieben wird, dann
wird die Interface-IP als src IP verwendet.
 
> > b) Übersichtlichkeit, wenn DNS wieder nicht erreichbar ist und ich
> >   debuggen muss - die IP vom Tunnelserver kenn' ich auswendig, aber
> >   wenn der 40 IPs hat, dann werd' ich mir die nicht alle merken.
> Du braucht die Main-IP des Tunnelservers, mehr sollte dich erstmal
> nicht interessieren.

Na aber solang mir traceroute, ping -R, etc Interface-IPs ausspucken,
seh ich die Main-IP halt einfach gar nicht. Eben Linuxrouting nicht
OLSR Routing, das hier am Werk ist.

> Andererseits könnte man bei wichtigen Servern vielleicht ein
> modifiziertes Nameservice-Plugin einsetzen was alle Interfaces in der
> Form
> 
> vpn0.<name der OLSR Node>
> eth0.<name der OLSR Node>
> 
> jeweils in die DNS-Tabelle einfügt.
> 
> Wäre beim Debuggen eines solchen Servers bestimmt nützlich.

Hm, das Nameservice-Plugin verwenden wir gar nicht (zurecht, es ist
IMHO eine mühsame Krücke), aber in solchen Fällen würd's natürlich
ein bisschen helfen.

> > c) Es gibt nur ca. 3*10^9 verschiedene IPs und Funkfeuer ist nicht
> >   allein auf der Welt. Ein typischer Knoten hat zwei devices, das
> >   macht dann 4 IPs/User! - Es wurde schon vorgeschlagen, das Problem
> >   durch die Verwendung von IPs aus 10.0.0.0/8 zu lösen, aber da
> >   waren auch viele Leute dagegen, eben weil die IPs immer wieder
> >   wo auftauchen.
> Das Problem wird sich mit IPv6 lösen... außerdem muß ja nur eine
> öffentliche IP pro Standort (weder pro Interface noch pro Router)
> sein, der Rest... nunja, der wird sowieso nur für die "next Hops"
> genutzt.

Ja, die meisten anderen Probleme, die wir oben diskutiert haben, werden
sich mit IPv6 auch lösen (link local Adressen, etc).

Das Problem ist halt auch, dass sich hier in Wien eine Menge Leute 
gegen das "eine öffentliche IP pro Standort" gestellt haben. 

> > d) Der olsrd hat bugs, die bei Knoten mit verschiedenen IPs auftreten.
> Kannst du das nähere Erklären ?
> 
> Im Normalfall haben alle Knoten verschiedene IPs.
> 
> >   Ironischerweise wurde der Fix von Markus mit der Begründung
> >   "nicht RFC konform" auf die lange Bank geschoben. (Hab' das dann
> >   nicht mehr weiter verfolgt, also sorry, falls der Punkt inzwischen
> >   aufgelöst ist...)
> Solltest du auf den Wechsel der Main-IP anspielen (wenn das 1.
> Interface des OLSR down geht), das kann im TIP einfach dadurch gelöst
> werden das du deine Router-ID (und nichts anderes ist die Main-IP)
> einfach im Config-File angibst.

Nein, ich hab' das hier gemeint:
http://lists.olsr.org/pipermail/olsr-dev/2008-December/002729.html


Liebe Grüße,
Harald