[Berlin-wireless] wie entstehen routen-loops

[Sven-Ola Tuecke]

Hi,

zum Managed-Mode hab' ich auch was zu sagen. Ein Access Point wiederholt alle 
Pakete mit der Broadcast-MAC-Adresse von alleine. Moeglicherweise - bei 
entsprechender Konfi - sogar Multicast-MAC-adressierte Pakete. Unicast ist 
was anderes. Da muesste der AP "gezielt" wiederholen, eben so wie ein 
normaler Layer3-Switch. Es duerfte daher guenstiger sein, die indirekte 
Verbindung via AP auch im Routing abzubilden.

Beim Lesen der Mails ist mir da eine Idee gekommen. Mal herumprobieren: was 
passiert eigentlich, wenn die Clients die IP des Access Points als 
"IP4BroadcastAdress" verwenden? Dann kann man sich evt. iptables und 
linkqualitymults etc. schenken. Und iptables einfach dazu nutzen, die 
Verwendung der AP-IP als Broadcast-Adresse fuer die Clients sicherzustellen.

Grusz, Sven-Ola

Am Freitag 17 Februar 2006 21:50 schrieb Marco Tidow:
> On Fri, Feb.17. 17:12 +0100, onelektra wrote:
> > Hi -
>
> Hi,
>
> > Woher kommt das?
> >
> > * Jemand hat von Hand an den Routingtabellen schraubt und solche
> > Kreisläufer gebastelt.
>
> Ack.
>
> > * Der Routingdeamon schafft es nicht die Routingtabellen zu
> > synchronisieren
>
> "synchronisieren" ist etwas unglücklich gewählt; obwohl es genau darum
> geht, eben um loops zu vermeiden, daß die router ihre Tabellen möglichst
> zeitnah den aktuellen HF-Wegen anpassen.  Doch eine zentrale Referenzquelle
> als Grundlage der routing-Entscheidung, die allen und zur selben Zeit zur
> Verfügung steht, gibt es nicht.
>
> Um so mehr, als daß seit fisheye die Ausbreitung der link-quality info's
> länger dauert, stellen nodes ihr routing so verschieden schnell auf eine
> Änderung der HF-Wege neu ein.
>
> > * Bugs in OLSR
>
> Dazu mal eine Frage, nämlich nach dem Verbleib und Sinn der MPR
> (Multi-Point-Relay) Mechanik im olsrd.  IMHO vom Konzept her gedacht,
> einerseits die Zahl der nodes zu reduzieren, die ihre Umgebung mit
> "über-Nachbar-Grenzen-hinaus- reichenden" Verbindungs-info's
> belästigen/versorgen, was angesichts der exponentiell zunehmenden
> node-anzahl einen wohl erheblichen CPU-Last mildernden Effekt hätte?
>
> Andererseits dadurch auch "Synchronisierer", weil sich die nicht-als-MPR-
> selected-nodes nach demselben link-quality-Bild des nodes-Haufens richten,
> wie der jeweilige MPR, anstatt jeder für sich und zwangsläufig
> "asynchroner"?
>
> Nur fällt es mir schwer, trotz mittlerweile wieder auf "7" gesetzter
> MprCoverage MPR-selections und Wirkung zu erkennen.
>
> > * Die CPU-Last in den Nodes ist so gross, dass OLSR nicht mehr mit dem
> > Berechnen der Routingtabellen klar kommt und verrückt spielt
>
> Ack.
>
> Hier widerspricht sich der Wunsch, immer weiter zusätzliche nodes ins Netz
> zu bekommen, und die Notwendigkeit, Verbindungsinfo aller link-Strecken an
> alle nodes zu verteilen, und das so schnell es irgendwie geht, um
> günstigsten- falls innerhalb des timeouts der retry-Versuche des TCP-stacks
> Packete auf einen funktionierenden Weg zu bringen.
>
> > * Wenn OLSR-Nodes über Infrastruktur-Links funken und der Master-Node
> > ebenfalls OLSR auf dem AccessPoint-Interface spricht führt das zu Chaos,
> > einschliesslich Loops. Olsrd glaubt, dass der AP und seine Clients
> > sämtlich Single-Hop-Nachbarn sind. Sind sie aber nicht, da der AP
> > zwischen den Clients als Basisstation sitzt und als Bridge agiert. Olsrd
> > wird in diesem Fall wahrscheinlich dank ETX versuchen den AP als Router
> > zwischen den Clients einzutragen - was keinen Sinn macht, da dieser das
> > ohnehin transparent tut. Ausserdem kann es u.U. passieren, dass Olsrd
> > versucht um den AP herumzurouten - was ebenfalls keinen Sinn macht.
>
> Aeh, ein als bridge arbeitender master (AP) ist "unsichtbar" für das über
> seinen ethernet-port angeschlossene interface, und den darauf und mit
> dessen Adresse laufenden olsrd.
> Er braucht/hat keine eigene IP im zu bridge-nden Netz.  Macht also keinen
> Ärger.
>
> Ein "Accesspoint-router" ist dasselbe, also eine bridge, die aber mit
> der LAN-Seite eines routers fest verbunden ist.  Auch hierbei braucht der
> router-Teil keine eigene IP im Funk-Netz, solange man verkabelte olsr-
> Gegenüber ausschließlich an seine LAN-ports dranhängt.
>
> Probleme entstehen (weil ein router eben "routen" will ;-), wenn man
> über seinen WAN-port dasselbe subnet erreichen will, das auch für die
> LAN-/Funk-clients gilt.  Meistens zwingt das Konzept des routing-
> Teils, auf der LAN-Seite mit einer kleineren, statischen netmask
> zu arbeiten, als auf der WAN-Seite.  Damit kommen die oben von
> elektra als "Punkt 1" genannten manuellen routen ins Spiel.
>
> Als Faustformel kann man vielleicht sagen, sobald man versucht ist,
> einem Ap-router eine IP-Adresse zu geben, um "über ihn" Funk-traffic
> zu schicken, Finger wech :-)
>
> > cu elektra
>
> bei Gelegeheit, marco
>
>
> _______________________________________________
> Berlin mailing list
> Berlin at olsrexperiment.de
> https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin

_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin