[Discuss] IP-Adressen + Routing

[Bernd Petrovitsch]

Nachdem ich gestern den Aaron diesbezüglich nicht quälen konnte (zuviel
sonstiger Andrang und untiges hat ja Zeit):

Ich hab noch immer das seelische (und alle irgendwann mbMn das
praktische) Problem, daß ich ein 0xFF-Interface (sei es am Tunnel oder
ein "echtes") als z.B. 1.2.3.4/24[0] konfiguriert hab - und ich weiß
v.a.  nicht, ob das ein Problem in der Theorie, in der Praxis oder in
der OLSRD-Implementierung ist:
Konkret sind auf meiner Kiste 2 solche konfiguriert, 1.2.3.4/24 am
Tunnel-Interface und 1.2.3.5/24 am echten Eth, wo mal ein LinkSys
dranhängen wird. Die (automatisch erzeugten) Routen auf das 1.2.3.0/24
Netz werden latürnich explizit ehebaldigst wieder gelöscht.
[ Rein seelisch würde ich da 1.2.3.4/32 bzw. 1.2.3.5/32 konfigurieren,
weil das so wirklich korrekt ist. ]
Nur muß der OLSRD wissen, wie er broadcasten muß, um andere OLSRDs im
Netz zu erreichen. Im Moment macht er das (AFACT) als IP-Broadcast über
das Netz+Maske des Interfaces. Das impliziert, daß auf allen anderen
Seite (im Prinzip) dasselbe Netz konfiguriert sein muß. Daraus folgt
(mbMn zwingend) daß im gesamten Netz dasselbe Netz+Maske verwendet
werden muß, weil ja jeder Knoten potentiell überall erscheinen
könnte[1].
Daraus folgt direkt das der Liste der Netze eine administrative
Entscheidung zu Grunde liegt (welche Netze werden tatsächlich im
0xFF-Netz verwendet) und nicht die lokale Konfiguration des
IP-Interfaces (jedem IP-Interface eine IP-Adresse aus jedem Netz zu
geben hilft ja auch nicht).

Das führt zum (ganz oben erwähnten) praktischen Problem, wenn es mal
mehrere Netze gibt (egal ob öffentlich vom RIPE oder privat a la
RFC1918).
Eine Trennung in "Transportnetz" mit privaten IP-Adressen + öffentliche
über HNA announcet scheint mir zu einschränkend/nicht zweckmäßig/mit
unnötigen laufenden administrativen Aufwand verbunden wegen Host von
einem Netz ins andere.

Welche Lösungen seh' ich:
1) OLSRD-Interfaces bekommen IP-Adressen aus einem definierten großen
   privaten Netz und über das wird per definitionem gebroadcastet.
   0xFF hatte das Mal und es ist umgestellt worden (k.A. über dieDetails
   des warum).
   [ Öffentliche würden nur dort zusätzlich konfiguriert, wo es Sinn
   macht und automatisch oder explizit per HNA announcet. ]
2) Es gibt mehrere definierte Netze und der OLSRD broadcastet in alle
   diese rein - die muß man natürlich dann im olsrd.conf explizit für
   alle relevanten Interfaces korrekt einstellen.
   D.h. der normale LinkSys (oder Tunnelendpunkt) bekommt ein private
   IP-Adresse (und sind damit vom großen Internet nicht mehr sichtbar -
   was mbMn mehr Vor- als Nachteil ist) und routet alle definierten
   Netze, PC, Servers, Firewalls bekommen offizielle IP-Adressen.
   Dafür kann man das einzelne IP-Interface als /32 (aus irgendeinem der
   definierten Netze) konfigurieren.

Welche Nicht-Lösungen seh ich:
a) Mehr öffentliche Netze und gut ist. Naja, die werden kaum zu den im
   Moment existierenden dazupassen, d.h. spätestens dann gibt es (mind.)
   2 verschiedenen Netze.
b) NAT auf allen Uplinks: Hatten wir. Wollen wir nicht, wenn es sich
   vermeiden läßt (d.h. bei "echten" Uplinks mit BGPv4 Routing etc.).

2) ist mbMn die elegante Lösung. olsrd.conf *muß* sowieso korrekt
konfiguriert werden (HNAs stehen da sowieso auch explizit drin) - da
kommt es auf die "offiziellen" OLSR-Netze als zusätzliche Parameter
nicht mehr an. Sanfte Migration ist mbMn damit möglich.

Was hab ich übersehen bzw. vergessen (nein, OLSR-RFCs hab ich keine
gelesen)? Welche Stolpersteine/Hindernisse/Probleme/Bedenken
(theoretischer, administrativer oder technischer) gibt es und v.a.
warum?
Welche anderen Lösungen (außer dem "Ostrich-Algorithm") und
Nicht-Lösungen hab ich vergessen?

	Bernd, in der Hoffnung auf konstruktive und erschöpfende
               Antworten

[0]: IP-Adressen+Netzmaske simplifiziert, damit es einfacher in meinem
     Kopf ist.
[1]: Am Rand des Netzes - d.h. den administrativen Grenzen kann es
     natürlich verschiedenen Netze geben, aber sowas will man idR nicht
     haben, wenn es sich vermeiden läßt.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services