[Wien] Viele IPs offline und es dürfte noch schlimmer werden!

Sa Nov 23 23:39:36 CET 2013

Hallo Bernd, 
danke für die Steilvorlage, ich gehe gerne darauf ein ... (ich hoffe nicht zu umfangreich)

On 19.11.2013, at 10:18, Bernd Petrovitsch wrote:

> Hi!
> 
> On Mon, 2013-11-18 at 18:04 +0100, Matthias Šubik wrote:
> [...]
>> Letztes bräuchte ein REST-API, mit dem sich der Router einfach eine IP holt.
> 
> Genau, am besten eine Tomcat-basierte Webapplikation, um eine 4 Byte
> große IP-Adresse beim Booten aufzutreiben. SCNR ....
> 
Ich habe halt sehr in Beispielen geschrieben. REST-API stand für mich für etwas, das Du in einem simplen SysV-Init, rc.local whatever script mittels curl/wget/devtcp fragen kannst, und für Deinen Identifier (MAC?) eine Konfiguration zurückbekommst.

DAs geht natürlich auch mit DHCP, wenn wir dhcp relay einsetzen.
> [...]
>> ps: Und alle hochtrabenden Diskussionen was und wie laientauglich sein
>> muss oder sollte, ist ein Holler, weil 15 Jahre (!) seit RFC von DHCP
>> noch IPs von Hand IRGENDWO einzustellen doof ist. Wir können mal
> 
> Dann schau mal einem "Laien" zu, wenn er Bootprobleme mit DHCP debuggen
> soll (so a la "Windoof sagt 'kein Netzwerkanschluß', woran liegts es?".
Ich habe nicht an Windows auch nur gedacht, sondern an einen Meshteilnehmer (router/embeddedwhatever).
Hierbei gibt es alleine schon das Problem, dass es keine lokale Konsole gibt,
dass es weiterhin für "Laien" manchmal schwierig ist, Maske, IP und DNS richtig den Feldern einer Maske zuzuordnen, und dann auch noch richtig und ohne Zahlendreher abzuschreiben.
> Das schaut bei "Kabel ausgesteckt" und "DNS-Server nicht erreichbar"
> leider sehr identisch aus. Nur wenn man double-NATTing macht, gibt es
> noch mehr mögliche Bruchstellen ...).
Hier macht Windows was richtig (selten aber doch), ein Device ist halt nur dann ready, wenn es ready ist. Es macht aus vielen Zuständen zwei, an der Fehlerbeschreibung kann man ja arbeiten. Wichtig ist die Erkenntnis, *es geht nicht*, weil der "Laie" bei einer Fehlermeldung wie "DNS Server antwortet nicht" sich fragen muss "brauch ich den, oder klick ich das weg?". 
> Und bei einem Netz, wo - definierterweise - jeder Herr, Meister und
> Admin seiner eigener Knoten ist wird dann von oben (hahaha;-) befohlen,
Kann, nicht muss. Aber wer seinen Knoten nicht wieder anfassen will, nur weil der wegen Schneelast, Netzteil-tot, oder einfach nur Auslandssemester ungeplanterweise sechs Monate offline war, ist über eine Automatik für fertig eingerichtete Router vielleicht ganz glücklich.
> einen zentralen DHCP-Server zu benützen?
Auch das ist nicht notwendig, ich lache nur immer wieder, wenn ich in diversen Funk-Wikis IP Adresslisten von 10.x.y.z IPs lese, die sowieso schon logisch zugeordnet sind, dann aber trotzdem noch in masochistischer Art und Weise trotzdem händisch gepflegt werden. Egal ob WLAN oder HAMNet-Initiative, es gibt soviele Bussysteme die es schaffen automatisch zu adressieren, warum nicht auch mesh-Netze? Da mache ich halt einen DHCP Server pro existierendem Knoten, der mit seiner Konfiguration (siehe ganz oben) auch eine Subnetzmaske für seine Links bekommen hat. Dann hat jeder Nachbar eine IP, ganz automatisch, und kann sein Device aus einer Logliste fischen, und gleich online administrieren, oder sich die IP per e-Mail schicken lassen, oder oder oder.
> Das ist hier wohl ein schlechter Kompromies zwischen Autonomie und
> DAU-Tauglichkeit.
Autonom bist Du nicht, nur weil Du aus dem IP-Pool von 0xFF eine Adresse händisch eingibst. Du bist in dieser Range gefangen, die IP kann jederzeit borderseitig gesperrt werden, und sicher auch durch gezielte fremde Announcements.
Autonom bist Du, wenn Du Deine "eigene" Range im Mesh fährst, die Dir z.B. von einem LIR/RIR statisch zugeteilt wurde.

> 
> Und DHCP umschifft ja lediglich das Problem, auf einem Gerät ein
> IP-Adresse explizit konfigurieren zu müssen. Und das hat überhaupt
> nichts damit zu tun, wie die IP-Adressen im Netz verteilt werden - von
> einem extrem - komplett statisch (lies: dhcps.conf aus der DB erzeugt) -
> bis zum anderen extrem - nur dynamisch aus Pools (und den DNS-Server
> kann bzw. muß man auch gleich damit füttern und auch überall die
> Hostnamen dazuschreiben, wenn die IP-Adresse wandern kann ....).
+1 dafür, DHCP ist nur ein kleiner Schritt, nämlich der, dass offline IPs nach Ablauf des Lease ohne Intervention sicher wieder vergeben werden können, und löst nicht die "Policy-Frage", nämlich wer, wann, wie viel, wie lange.
Ich habe mich in den letzten Jahren vom Zuweisungsfan zum "alles dynamisch"-Vertreter gewandelt. 
Nur als Beispiel: Firewire hat dynamische Busadressen, die braucht nur niemand wissen. Von so einer Lösung träume ich. Du erwähnst auch die Adressierbarkeit, hier könnte man ja eine simple Monitor-Seite haben (wie openvpn), wo einfach MAC->IP (aktuelle ganz oben) gelistet sind. Schnell gemacht, und der ID-Aufkleber ist auf den meisten Routern schon drauf.
> Ah ja, und der DHCP-Server wird dann zu kritischen Ressource im Netz ...
1. isc-dhcpd kennt master/slave, 2. lease 36h, dann gibt es deutlich kritischere Services (Gateway/DNS), von denen einer z.Zt. auch nicht gerade redundant ist ;) 3. not-authoritative DHCP kannst Du so viele haben wie Du willst. Mit ping-before-offer laufen die auch alle ganz friedlich nebeneinander her, weil RENEW macht der dhcpcd ja imemr mit dem Server von dem er die IP ursprünglich hatte.
> 
> Sorry, aber das sind 2 ganz verschiedene Dinge - schon weil ersteres
> (wie erfährt $GEREAT seine IP-Adresse) ein technisches/organisatorisches
> und zweiteres (welches Gerät bekommt eine - und welche - öffentliche
> IP-Adresse) ein soziales/politisches Problem ist.
+1,
aber auch hier wieder mein Appell: einfach, flach, gewürfelt ...
Beispiel: dhcp-relay + minimum proxy auf jedem node, damit bekomme ich mit JEDEM wlan client eine IP, komme soweit ins (Funkfeuer)-Netz, dass ich zu einem backfirevienna für das device komme, und weil wir so sozial sind, darf ich orf.at auch lesen (oder was auch immer noch, weil ich habe ja MAC, ungefähre Ortsangabe, und fertig). 
Dann kann ich flashen, und wenn die Automatik da auch drin ist, ist das Gerät an jedem Standort, egal ob getauscht, oder verliehen, einfach wieder online. Nie wieder IP umstellen, und DNS Namen kann ich an die MAC binden (CNAME von nodeOrt auf nodeAABBCCDDEEFF), ist also weder an IPv4 noch eine spezielle Adresse gebunden.

> 
> Da hilft schon eher, daß alle Knoten, die nichts weltweit relevantes
> anbieten (lies: der durchschnittliche LinkSys), RfC-1918 IP-Adressen
> verwenden. Klarerweise kann man die nicht mehr von außen pingen, aber
> braucht es das? Pro Location 1 Gerät mit öffentlicher IP-Adresse und von
> dort kann man lokal auf "seine" Nodes immer noch weiter.
Oder das, es ist vom Prinzip her kein Unterschied, man könnte das sogar mischen. Bei entsprechend intelligentem (komplizierten?) Backend, kann ich sogar bestimmte MACs für eine öffentliche IP eintragen. Wichtig für mich ist:

1) kein manuelles Management mehr notwendig (client)
2) kein manuelles Management mehr notwendig (vergabe)
3) keine administrative hürde später, wenn devices zwischen Nutzern getauscht werden, verliehen, sonst was.
> 
> *eg* oder gleich IPv6 .....
Das ist alles genau gleich, IP sollte automatisch kommen, und fertig.
Das war der Grund, warum ich die Bindung an die NodeID, und manuelles Rechnen für alten (sehr guten) Wein in neuen Schläuchen halte. Man braucht es nicht. Bei der Zahl an Nodes die in 0xFF-Wien in den nächsten Jahren sind, kann ich jedem Link ein beliebiges Prefix dynamisch zuteilen, und der einzige Zuwachs an Daten sind die Prefixe statt den bisherigen OLSR-Routing-Einträgen. Statt 200 IPv4, stehen da dann halt 200 IPv6-Prefixe in der Table. Und wenn der Automatismus sogar alle Links an einem Node aus einem Prefix nimmt, dann sind es sogar weniger Einträge.

Ich hoffe das war noch nicht zu viel um es zu lesen.
Matthias
ps: Das gesamte Mesh einfach als ein virtuelles EUI-64 zu adressieren wäre fast verhaltensorginell, aber trotzdem vermutlich ohne Verwaltungsaufwand möglich.

-- 
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Wien mailing list
(spam-protected)
https://lists.funkfeuer.at/mailman/listinfo/wien