Discussion:
[Wien] Knoten biss - Netzwerkpflege
Christian Pock
2018-06-30 15:16:32 UTC
Permalink
Hallo allerseits,

Mir fällt bei den Nachbarn von biss die Unregelmäßigkeit auf, dass diese sich gegenseitig alle als OLSR-Nachbarn sehen. Da scheint der Traffic von den Antennen ungehindert über die andern Funkstrecken weiterzulaufen.
Ich da was "kaputt"?

Im Sinne eines "sauberen Netzwerks" halte ich es für wichtig, dass

1) OLSR-Nachbarn maximal 1 Funkstrecke trennt, nicht mehrere. Das wird aktuell nicht eingehalten z.B. bei biss, aber auch metalab/vkm/conesphere, garten94.

2) OLSR-interfaces eine IP mit Mask /32 bzw. 255.255.255.255 nutzen. Das ist leider bei zahlreichen Geräten nicht so (oft mit /22 oder /24 in Betrieb) und macht daher Probleme beim gegenseitigen Erreichen von Knoten oder beim Erreichen von Housing-Servern (z.B. DNS).

Ich halte Netzwerk-Pflege für wichtig und finde, sie ist - ähnlich wie regelmäßige Softwareupdates - Teil der Wartung unseres (!) gemeinsamen Netzwerks, damit wir es nicht versandeln und zerfallen lassen.

Falls jemand Unterstützung bei Konfigurationsbereinigung benötigt, so helfe ich gerne aus wo geht!

LG, Christian
Erich N. Pekarek
2018-06-30 16:16:15 UTC
Permalink
Hallo,
Post by Christian Pock
Hallo allerseits,
Mir fällt bei den Nachbarn von biss die Unregelmäßigkeit auf, dass diese sich gegenseitig alle als OLSR-Nachbarn sehen. Da scheint der Traffic von den Antennen ungehindert über die andern Funkstrecken weiterzulaufen.
Ich da was "kaputt"?
Ja: Akku hat meines Wissens vor etwa 10 Tagen einen nicht mehr reaktiven
EdgeRouter dort durch einen simplen Switch ersetzt.
Christofer hat angeboten, den EdgeRouter zu servicieren, soweit dies
möglich ist.

Es handelt sich demnach um ein Interim.

@Akku: wie schaut es denn aus?
Post by Christian Pock
Im Sinne eines "sauberen Netzwerks" halte ich es für wichtig, dass
1) OLSR-Nachbarn maximal 1 Funkstrecke trennt, nicht mehrere. Das wird aktuell nicht eingehalten z.B. bei biss, aber auch metalab/vkm/conesphere, garten94.
Ack!
Post by Christian Pock
2) OLSR-interfaces eine IP mit Mask /32 bzw. 255.255.255.255 nutzen. Das ist leider bei zahlreichen Geräten nicht so (oft mit /22 oder /24 in Betrieb) und macht daher Probleme beim gegenseitigen Erreichen von Knoten oder beim Erreichen von Housing-Servern (z.B. DNS).
Bitte bedenke, dass einige Teilnehmer die umfassenderen Netzmasken für
Wartungszwecke einsetzen. Sauberer wäre freilich ein VLAN oder zumindest
ein Interface-Alias. Ob dafür taugliche Firmwares und Know How vorhanden
sind, wäre zu evaluieren.

Was haltet Ihr davon, wenn wir eine Feature-Tabelle anlegen, in der die
bekannten Devices erfasst sind, und wo Node-Owner Infos ergänzen können?
Gibt es Bedenken gegen eine solche Datensammlung?
Post by Christian Pock
Ich halte Netzwerk-Pflege für wichtig und finde, sie ist - ähnlich wie regelmäßige Softwareupdates - Teil der Wartung unseres (!) gemeinsamen Netzwerks, damit wir es nicht versandeln und zerfallen lassen.
Falls jemand Unterstützung bei Konfigurationsbereinigung benötigt, so helfe ich gerne aus wo geht!
Bitte schreib das auch ins Forum und leg dort auch einen eigenen Thread
dafür an. Ich finde die Idee gut und werde Dich in dieser Bestrebung
unterstützen, so es mir möglich ist. +1
Post by Christian Pock
LG, Christian
--
Wien mailing list
https://lists.funkfeuer.at/mailman/listinfo/wien
LG
Erich
Markus Kittenberger
2018-06-30 21:44:47 UTC
Permalink
Post by Christian Pock
2) OLSR-interfaces eine IP mit Mask /32 bzw. 255.255.255.255 nutzen. Das
ist leider bei zahlreichen GerÀten nicht so (oft mit /22 oder /24 in
Betrieb) und macht daher Probleme beim gegenseitigen Erreichen von Knoten
oder beim Erreichen von Housing-Servern (z.B. DNS).
Eigentlich sollte es nur unnötigen Traffic (arprequests) und dann evt.
andere icmp fehler als unreachable in Bezug auf Devices verursachen die in
dem Moment per olsr sowieso nicht erreichbar sind.

Das hat zwar dann vielleicht Auswirkungen darauf wie lang nach einem kurzen
olsr hickup oder reboot eines routers, etc., oder wasauchimmer die
eigentliche Ursache fÃŒr die Probleme ist, es dauert bis der gewÃŒnschte Host
auf dem eigenen Computer wieder erreichbar ist, aber /22 /23 /24 sind IMHO
nur unschön aber nicht wirklich falsch, /25 oder kleiner wÀren aber dann
definitiv ein Problem, denn da wird die falsche netz bzw broadcast IP die
aber potentiell jemand gehört, von transitroutern quasi geblackholed !

Jedfalls erreichbare Devices mit ÃŒberall vorhandenen olsr Hostrouten sind
gleich gut erreichbar, egal ob da /22 /23 /24 auf den transitknoten
konfiguriert sind, in der Anfangszeit von funkfeuer verwendete niemand ein
/32. Der Einheitlichkeit wÀre es aber nun halt schöner Ìberall /32 zu haben.
Post by Christian Pock
Was haltet Ihr davon, wenn wir eine Feature-Tabelle anlegen, in der die
bekannten Devices erfasst sind, und wo Node-Owner Infos ergÀnzen können?
+1 falls das eine Tabelle sein soll (incl Spalten fÃŒr die weitverbreiteten
firmwares) die "alle" Features bzw Konfigs auflistet die olsr gerÀte in
unserem Netz haben bzw beachten könnte oder soll bzw. muss!

Gibt es Bedenken gegen eine solche Datensammlung?
Nein, ist eher ne Notwendigkeit fÃŒr ein reibungslos funktionierendes Netz,
und ein wichtige Informationsquelle fÃŒr Firmware und Node maintainer, die
ja im Grunde nie absichtlich falsche oder suboptimale Konfigurationen
wÀhlen (wollen).

Und beteilige mich da auch gern dabei diese Tabelle zu befÃŒllen, bzw. afair
gabs ja auch dergleichen schon mal irgendwo in irgendeinen wiki ....

LG Markus
Christian Pock
2018-07-01 07:34:54 UTC
Permalink
2) OLSR-interfaces eine IP mit Mask /32 bzw. 255.255.255.255 nutzen. Das ist leider bei zahlreichen GerÀten nicht so (oft mit /22 oder /24 in Betrieb) und macht daher Probleme beim gegenseitigen Erreichen von Knoten oder beim Erreichen von Housing-Servern (z.B. DNS).
Eigentlich sollte es nur unnötigen Traffic (arprequests) und dann evt. andere icmp fehler als unreachable in Bezug auf Devices verursachen die in dem Moment per olsr sowieso nicht erreichbar sind.
Das hat zwar dann vielleicht Auswirkungen darauf wie lang nach einem kurzen olsr hickup oder reboot eines routers, etc., oder wasauchimmer die eigentliche Ursache fÌr die Probleme ist, es dauert bis der gewÌnschte Host auf dem eigenen Computer wieder erreichbar ist, aber /22 /23 /24 sind IMHO nur unschön aber nicht wirklich falsch, /25 oder kleiner wÀren aber dann definitiv ein Problem, denn da wird die falsche netz bzw broadcast IP die aber potentiell jemand gehört, von transitroutern quasi geblackholed !
Jedfalls erreichbare Devices mit Ìberall vorhandenen olsr Hostrouten sind gleich gut erreichbar, egal ob da /22 /23 /24 auf den transitknoten konfiguriert sind, in der Anfangszeit von funkfeuer verwendete niemand ein /32. Der Einheitlichkeit wÀre es aber nun halt schöner Ìberall /32 zu haben.
Also ich hatte beobachtet, dass ohne HNA /25 fÃŒrs Housing zahlreiche Router nicht mehr das Housing (den DNS da) erreichen. Betroffen davon waren
-) Router mit /24 und größer als IP-Mask
-) alle Router "dahinter"

Wolltest du das damit sagen?

Also ja, meiner Meinung nach ist das mehr als "nur unnötiger Traffic" und wÀre gut, wenn man behebt, um den (relativ großen Teil des betroffenen Netzwerks) nicht von HNA/25 anhÀngig zu machen. Dir meisten Nutzer haben eine Funkfeuer-DNS aus dem Housing konfiguriert.

LG
Thomas Mutschlechner
2018-07-01 10:06:02 UTC
Permalink
Am 30.06.2018 um 23:44 schrieb Markus Kittenberger
Post by Christian Pock
 
2) OLSR-interfaces eine IP mit Mask /32 bzw. 255.255.255.255
nutzen. Das ist leider bei zahlreichen Geräten nicht so (oft mit
/22 oder /24 in Betrieb) und macht daher Probleme beim
gegenseitigen Erreichen von Knoten oder beim Erreichen von
Housing-Servern (z.B. DNS).
Eigentlich sollte es nur unnötigen Traffic (arprequests) und dann evt.
andere icmp fehler als unreachable in Bezug auf Devices verursachen
die in dem Moment per olsr sowieso nicht erreichbar sind. 
Das hat zwar dann vielleicht Auswirkungen darauf wie lang nach einem
kurzen olsr hickup oder reboot eines routers, etc., oder wasauchimmer
die eigentliche Ursache für die Probleme ist, es dauert bis der
gewünschte Host auf dem eigenen Computer wieder erreichbar ist, aber
/22 /23 /24 sind IMHO nur unschön aber nicht wirklich falsch, /25 oder
kleiner wären aber dann definitiv ein Problem, denn da wird die
falsche netz bzw broadcast IP die aber potentiell jemand gehört, von
transitroutern quasi geblackholed !
Jedfalls erreichbare Devices mit überall vorhandenen olsr Hostrouten
sind gleich gut erreichbar, egal ob da /22 /23 /24 auf den
transitknoten konfiguriert sind, in der Anfangszeit von funkfeuer
verwendete niemand ein /32. Der Einheitlichkeit wäre es aber nun halt
schöner überall /32 zu haben.
Also ich hatte beobachtet, dass ohne HNA /25 fürs Housing zahlreiche
Router nicht mehr das Housing (den DNS da) erreichen. Betroffen davon waren 
-) Router mit /24 und größer als IP-Mask
-) alle Router "dahinter"
Wolltest du das damit sagen?
Also ja, meiner Meinung nach ist das mehr als "nur unnötiger Traffic"
und wäre gut, wenn man behebt, um den (relativ großen Teil des
betroffenen Netzwerks) nicht von HNA/25 anhängig zu machen. Dir meisten
Nutzer haben eine Funkfeuer-DNS aus dem Housing konfiguriert. 
Ich musste meinen Knoten so7 auf IP mit Mask /32 255.255.255.255
umstellen weil ein Teil des Netztes nicht erreichbar war. Können gernen
meinen Knoten zum Testen verwenden.

Lg Thomas
Thomas Mutschlechner
2018-07-01 17:49:59 UTC
Permalink
Post by Thomas Mutschlechner
Am 30.06.2018 um 23:44 schrieb Markus Kittenberger
Post by Christian Pock
 
2) OLSR-interfaces eine IP mit Mask /32 bzw. 255.255.255.255
nutzen. Das ist leider bei zahlreichen Geräten nicht so (oft mit
/22 oder /24 in Betrieb) und macht daher Probleme beim
gegenseitigen Erreichen von Knoten oder beim Erreichen von
Housing-Servern (z.B. DNS).
Eigentlich sollte es nur unnötigen Traffic (arprequests) und dann evt.
andere icmp fehler als unreachable in Bezug auf Devices verursachen
die in dem Moment per olsr sowieso nicht erreichbar sind. 
Das hat zwar dann vielleicht Auswirkungen darauf wie lang nach einem
kurzen olsr hickup oder reboot eines routers, etc., oder wasauchimmer
die eigentliche Ursache für die Probleme ist, es dauert bis der
gewünschte Host auf dem eigenen Computer wieder erreichbar ist, aber
/22 /23 /24 sind IMHO nur unschön aber nicht wirklich falsch, /25 oder
kleiner wären aber dann definitiv ein Problem, denn da wird die
falsche netz bzw broadcast IP die aber potentiell jemand gehört, von
transitroutern quasi geblackholed !
Jedfalls erreichbare Devices mit überall vorhandenen olsr Hostrouten
sind gleich gut erreichbar, egal ob da /22 /23 /24 auf den
transitknoten konfiguriert sind, in der Anfangszeit von funkfeuer
verwendete niemand ein /32. Der Einheitlichkeit wäre es aber nun halt
schöner überall /32 zu haben.
Also ich hatte beobachtet, dass ohne HNA /25 fürs Housing zahlreiche
Router nicht mehr das Housing (den DNS da) erreichen. Betroffen davon waren 
-) Router mit /24 und größer als IP-Mask
-) alle Router "dahinter"
Wolltest du das damit sagen?
Also ja, meiner Meinung nach ist das mehr als "nur unnötiger Traffic"
und wäre gut, wenn man behebt, um den (relativ großen Teil des
betroffenen Netzwerks) nicht von HNA/25 anhängig zu machen. Dir meisten
Nutzer haben eine Funkfeuer-DNS aus dem Housing konfiguriert. 
Ich musste meinen Knoten so7 auf IP mit Mask /32 255.255.255.255
umstellen weil ein Teil des Netztes nicht erreichbar war. Können gernen
meinen Knoten zum Testen verwenden.
Habs gerade auf so7 mit /22 255.255.252.0 getestet.
z.B. ping 193.238.156.225 zum DNS Server schlägt dann fehl.

Lg Thomas

Lesen Sie weiter auf narkive:
Loading...