Re: 2 neue Wiki Einträge: OpenVPN Start/Stop & OLSR Routen-Prio

[Tom Green]

Hi,

Also ich hab es gerade bei kleeV2 mal so eingetragen:

-----------
  # If a certain route should be preferred
  # or ignored by the mesh, the Link Quality
  # value of a node can be multiplied with a factor
  # entered here. In the example the route
  # using 192.168.0.1 would rather be ignored.
  # A multiplier of 0.5 will result in a small
  # (bad) LinkQuality value and a high (bad)
  # ETX value.


  # preferred link: fra1
  LinkQualityMult 10.50.252.48 1

  #next preferred best link: ro1
  LinkQualityMult 10.50.252.21 1

  # This multiplier applies to all other nodes
  LinkQualityMult default 0.8


  # If the NAT-Endpoint (the preferred 0/0 HNA emitting node)
  # is to be changed, the ETX value of the current 0/0 is
  # multiplied with the NatThreshold value before being
  # compared to the new one
  # The parameter can be a value between 0.1 and 1.0, but
  # should be close to 1.0 if changed.
 
  NatThreshold 0.6
---------

Er scheint so fra1 stabil zu halten. Bei NatThreshold 0.75 flackerte es
schon ein bisschen nach nue1. Komischerweise nicht nach ro1. Bei Dir
halt die Frage, ob das zurückschalten dann noch funktioniert. Eine
Alternative ist eine feste default-Route bbg nach fra1, die vom Tunnel
Skript überwacht und bei Bedarf deaktiviert wird.

Vom Abwurf über ro1 war ich letztes mal nicht angetan. Da gingen dann
kaum noch Daten drüber. Hoffentlich war das nur temporär, ansonsten ist
ro1 als Exit-node zumindest von Amsterdam aus nicht wirklich gut.

Wir können gerne heute Abend "Nürnberg ärgern gehen". So 23 Uhr?

Gruß
Torben



On 15.10.2015 10:38, Tobias Klaus wrote:
> Hey,
>
> Danke Tom für deine Arbeit!
>
> Diese Quality Geschichten würde ich ganz gern noch ein bisschen weiter 
> diskutieren, da ich denke das es hier 2 Probleme gibt.
>
> In dem wiki Artikel schreibst du ja, dass es dabei um den das "Gateway-
> Flattern" gehen soll. Der einfachste Weg das in den Griff zu kriegen sollte 
> das setzen von "NatThreshold" (wieder ein Wert zwischen 0.1 und 1.0 ):
>
> # If the NAT-Endpoint (the preferred 0/0 HNA emitting node)
> # is to be changed, the ETX value of the current 0/0 is 
> # multiplied with the NatThreshold value before being
> # compared to the new one.
>
> Das heißt er wechselt nicht immer gleich, aber halt wenn die Qualität des 
> aktuellen Gateways zu tief sinkt.
>
> # The parameter can be a value between 0.1 and 1.0, but
> # should be close to 1.0 if changed.
>
> Auch das sollten wir uns vermutlich dran halten.
>
> Beim Abwerten von Links(aufwerten funktioniert leider nicht :-( ) sollten wir 
> vermutlich auch vorsichtig sein. Allerdings macht wohl Sinn, die 
> "Hauptabwurfknoten" wie fra1 und ro1 mit 1.0(keine Abwertung) zu bewerten und 
> die restlichen vielleicht mit 0.8? Ich würde versuchen so wenig wie möglich in 
> die Entscheidungen von olsrd einzugreifen, aber versuchen Knoten mit Tunneln 
> zu entlasten, falls das geht.
> @Tom: Diese Werte würde ich ganz gern heute abend oder die Tage nochmal 
> ausprobieren.
>
> Grüße
> Tobias
>
>
> Am Donnerstag, 15. Oktober 2015, 09:00:08 schrieb Tom Green:
>> Hi,
>>
>>> hab ich dich jetzt richtig verstanden, dass das Olsr routen umbauen
>>> nur dann ->nicht<- richtig funktioniert wenn das TunnelIF zwar da ist
>>> (also tunX im ifconfig existiert) aber keine Daten (damit auch kein
>>> Ping) durchgehen? Bei meinem heutigen Test kam ich nämlich eigentlich
>>> zu einem anderen Schluss wobei ich dabei natürlich einfach das tunX
>>> bzw. OpenVPN abgeschossen habe (also das, was dein Script macht, wenn
>>> keine Daten mehr durch den Tunnel fließen).
>>>
>>> Hab ich das ganze soweit richtig verstanden?
>> Ja richtig. Es deckt den VPN-Anbieter seitigen Serverausfall ab.
>>
>>> und danke für die Erklärung von "LinkQualityMult" du hast damit das
>>> bestätigt, was ich mir heute morgen ausgemalt aber noch nicht getestet
>>> habe ;)
>>>
>>> Hoffe ich finde die Tage mal Zeit meine Kiste auch entsprechend zu
>>> konfigurieren, aktuell hab ich grad mal für ein paar Mails Zeit und
>>> morgen siehts auch nicht besser aus, vielleicht Freitag...
>> Warte noch auf Tobias, der hat die größere Erfahrung bei dem Thema und
>> die Konfig erstmals eingeführt. Vielleicht verbessert der noch was.
>>
>> Gruß
>> Torben
>>
>>> Am 14.10.2015 um 22:57 schrieb Tom Green:
>>>> Hallo Zusammen,
>>>>
>>>> Ich hab das Wiki noch ein bisschen aufgebohrt:
>>>>
>>>> https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen#OpenVPN_Sta
>>>> rt.2FStop_Automatik
>>>>
>>>> https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen#Priorisiere
>>>> n_von_OLSR_Routen
>>>>
>>>>
>>>> Wer mag, kann es sich zu Gemüte führen und kritisch reflektieren.
>>>>
>>>> Gute Nacht
>>>> Torben