Benutzer:Pocki

Aus FunkFeuer Wiki
Zur Navigation springen Zur Suche springen

Kontaktinfo

  • Name: Christian Pock
  • Mail: pocki (at) pocki.at

Maintainer

Ich bin (Co-)Maintainer von

Links

Privates Monitoring

OLSRv1-Status
OLSRv1-Map
OLSRv2-Status
OLSRv2-Map
Routen-Veränderungen
Outage-Simulator
Funkfeuer-Health-Monitor via uptimerobot.com

OLSRv1 Status

Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage.

Das Tool OLSRv1-Status holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden dann in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der offiziellen Funkfeuer-Map. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.

  • Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
  • Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
  • Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.

  • Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
  • Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

OLSRv1-Map

Visualisierung der Daten von OLSRv1-Status

Diese minimalistische Map verzeichnet nur jene Knoten und Verbindungen, die innerhalb der vergangenen 50 Tagen aktiv waren. Knoten und Verbindungen, welche schon länger offline sind, werden nicht mehr angezeigt.

Knoten sind in folgenden Farben markiert:

  • Grün: Teil Core-Netzwerk (=Layer2-Verbund des vlan33)
  • Blau: VPN-Endpunkt des Tunnelservers
  • Rot: normal übers Funknetz verbunden
  • Grau: aktuell offline

Verbindungen sind in folgenden Farben markiert:

  • Grün: aktuell verbunden
  • Türkis: aktull verbunden, monitoring deaktiviert
  • Rot: offline, war innerhalb der vergangenen 50 Tagen vorhanden
  • Rot-dunkel: offline, monitoring deaktiviert
  • Gelb: Verbindungen zwischen den Core-Netzwerk-Knoten

Klick auf den Node zeigt:

  • Node-Name und Node-ID laut Redeemer
  • Aktive OLSR Geräte mit IP und Hostname, MID werden nicht aufgezählt

OLSRv2-Status

Abfrage von OLSRv2-Infos von einem Roofnode-Router.

Erkennen von Node-ID/Node-Name aus den Redeemer-Daten, Originator oder Attached-Networks.

Stündlich scannt ein cronjob alle olsr(1)@IPv4-Geräte und ruft deren OLSRv2-IP-Adressen ab. Dabei wird auch ein ping6 zur Originator-IPv6 versucht (bis zu 3x). Die Ergebnisse fliessen in die Anzeige mit ein: IPv4 des IPv6-Routers, OLSRv2-Daemonversion, Ping-Ergebnis

Ping-Ergebnisse können sein:

  • OK: ping6 war erfolgreich
  • OLDOK: ping6 war erfolgreich, IPv4 konnte nicht ermittelt werden
  • PROBLM: ping6 war erfolgreich, der Router kommt aber nicht im OLSRv2-Broadcast vor!
  • ISOOK: ping6 war erfolgreich, obwohl der Route nicht im OLSRv2-Broadcast vorkommt und eigentlich isoliert erscheint
  • ISO: ping6 schlug fehl, der Router kommt nicht im OLSRv2-Broadcast vor und ist nicht via OLSRv2 erreichbar weil von der Domain abgeschnitten (isoliert)
  • ERR: ping6 schlug fehl, obwohl der Router im OLSRv2-Broadcast vorkommt und daher erreichbar sein sollte.

OLSRv2-Map

Visualisierung der Daten von OLSRv2-Status, vorhandene OLSRv1-Links werden grau eingeblendet um IPv4-Only-Nodes/Links zu zeigen.

Nodes sind in folgenden Farben markiert:

  • Grün: ok, an diesem Node ist ein OLSRv2/IPv6-Router aktiv und erreichbar
  • Rot: nok, dieser Node ist von der OLSRv2-Domain isoliert und nicht erreichbar
  • Blau: nok, dieser Node konnte mittels ping6 nicht erreicht werden
  • Weiß: nok, dieser Node ist nur mit olsr(1)@IPv4 erreichbar

Links sind in folgenden Farben markiert:

  • Grün: beide Linknachbarn sind erreichbar
  • Blau: einer der Linkpartner ist nicht teil des OLSRv2-Broadcasts, aber dennoch erreichbar
  • Rot: einer der Linknachbarn war mittels ping6 nicht erreichbar
  • Grau: keine OLSRv2-Verbindung, sondern nur olsr(1)@IPv4

Routen-Veränderungen

Jede Minute werden die Routen von 10 Nodes überprüft und Änderungen vermerkt. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben!

Outage-Simulator

Zeigt, welche IP-Adressen durch einen Router-Ausfall ebenfalls nicht mehr erreichbar sein werden.

OLSRd Uptime

Fragt das httpinfo-plugin (Port 8080) oder jsoninfo-Plugin (Port 9090) ab, um die Uptime und ggf. einen Restart des olsr-daemons festzustellen. Läuft alle 30min über die laut Topologie erreichbaren Router.

OLSRd-Uptime
OLSRd-Restarts

Funkfeuer-Health-Monitor

Der Service uptimerobot.com fragt alle 5min diverse IPs und HTTP(s)-Services ab und speichert Statistiken. Diese kann man über "Public Status Pages" und auch via API abfragen:

stats.uptimerobot.com/BPl2ySN2Q (direkt)
rpi3p.wehr24.wien.funkfeuer.at/health (PHP mit API als Datenquelle)
tunnel.funkfeuer.at/dash Dashboard auf dem OpenVPN-Tunnelserver mit einigen Connectivity-Infos

EdgeRouter-Wizards und Code

ER-wizard-Setup0xFF
ER-wizard-OLSRd_V1 - vchrizz
ER-wizard-OLSRd_V2
ER-wizard-AutoUpdate
ER-wizard-ebtables
ER-wizard-0xFF-WSLE Webstatus/LetsEncrypt
ER-wizard-OpenVPN-to-Tunnelserver
ER-SSH-Prelogin-Banner
ER-ping2web-watchdog
ER-load_ipv6_hostsfile
ER-showOlsrLinks-script
ER-bootLoaderUpdateCheck-script
ER-powerCycleEthPort-script
0xFF-BMK-webstatus - dabeani

ER-wizard-Setup0xFF

Der 0xFF-Setup-Wizard ist der einfachste und schnellste Weg, einen jungfräulichen (=befindet sich in factory default settings) EdgeRouter-X für den Betrieb mit Funkfeuer zu konfigurieren. Der Wizard enthält die Offline-Installations-Files für OLSR und OLSRd2 und kann daher ohne vorhandene Netzwerk- oder Funkverbindung angewendet werden. Minimal-Eingaben für eine Basiskonfiguration sind die Funkfeuer-IP und die Node-ID.

Vorgehensweise für die Anwendung/Installation des 0xFF-Setup-Wizards:

  • Download der aktuellsten Release vom Github: https://github.com/pocki80/ER-wizard-Setup0xFF/releases
  • Router mit Strom versorgen (bootet knapp 60sek) und Notebook/PC mit Port eth0 verbinden
  • am Notebook/PC eine fixe IP 192.168.1.2/24 vergeben (der Router hat per default an eth0 die IP 192.168.1.1/24, dhcp disabled)
  • im Browser die Page https://192.168.1.1/ aufrufen, eventuelle SSL-Zertifikatswarnungen akzeptieren/übergehen
  • Default-User "ubnt" und Default-Passwort beim Login eingeben, dann den Tab-Reiter "Wizards" aufrufen
  • in der Wizard-Liste (rechter Rand) auf "+" klicken, um den 0xFF-Wizard hinzuzufügen: Name "0xFF-Setup" eingeben, und die runtergeladene Wizard-TAR.GZ-File im Dateidialog auswählen, danach die Installation bestätigen.
  • in der Wizard-Liste (rechter Rand) den neuen 0xFF-Setup-Wizard auswählen (falls nicht schon passiert).

Von diesem Punkt an helfen die Texte direkt im Wizard bei der Initial-Konfiguration:

ER-wizard-OLSRd_V1

Installiert und konfiguriert den olsr (v1) daemon für IPv4 und IPv6. Seit 2017 wird für IPv6 allerdings nicht mehr der olsr(v1), sondern olsrv2 genutzt.

ER-wizard-OLSRd_V2

Installiert und konfiguriert den olsrv2 daemon für IPv6.

Dokumentation: OLSRd_V2_Wizard.pdf

ER-wizard-AutoUpdate

Ruft täglich die aktuelle Version auf github ab und installiert gegebenenfalls das aktuelle Update automatisch. Unterstützte Wizards sind: OLSRd_V1, OLSRd_V2, AutoUpdate, WSLE, ebtables

ER-wizard-0xFF-WSLE Webstatus/LetsEncrypt

Installiert einen zweiten lighttpd für eine Status-Seite und managed das SSL-Zertifikat mittels Lets-Encrypt.

ER-wizard-ebtables

Ermöglicht es, die Regeln zum Forwarden von Traffic für einzelne Bridges zu aktivieren (generell wird im Bridge-Setup des OLSRd_V1 das Forwarding zwischen den OLSR-Interfaces unterbunden).

OpenVPN-to-Tunnelserver

Wizard zum Einrichten und Verwalten eines OpenVPN-Tunnels zum Funkfeuer-Tunnelserver.

ER-SSH-Prelogin-Banner

Fügt der Welcome-Message vom SSH-daemon nützliche Informationen hinzu, um schon vor der Passwort-Eingabe erkennen zu können, um welchen Router und Standort es sich handelt. 

 CLI> curl -sS https://gist.githubusercontent.com/pocki80/e4c2c16c5c1b8886c8320446768a862f/raw/0xffedgebanner.sh | sudo bash

 Welcome to EdgeOS
           |                         |
  ,---.,---|,---.,---.,---.,---..   .|--- ,---.,---.
  |---`|   ||   ||---`|    |   ||   ||    |---`|
  `---``---``---|`---``    `---``---``--- `---``
            `---`      :: edgerouter-router ::
    Location: 1234, Knoten 4567
    Contact : meine@mailadresse.com
    SerialNo: AA:BB:CC:DD:EE:FF

Ping-2-Web watchdog

Script mit Cronjob, dass alle 12h einen Ping ins Internet absetzt. Bei Misserfolg wird der Ping innerhalb 4-11min wiederholt: bei neuerlichem Fehler wird 1min später der Router rebootet, dabei werden auch die angesteckten PoE-Ports einem PowerCycle unterzogen. 

 CLI> curl -sS https://gist.githubusercontent.com/pocki80/525cb16b95991c7efed1c053d82422fe/raw/set_ping2web.sh | sudo bash

ER-load_ipv6_hostsfile

Lädt einmalig alle bekannten OLSR2-IPv6-Adressen aus http://193.238.158.8/0xFF-BMK-webstatus/hosts_originators.txt in die lokale File /etc/hosts: 

 CLI> curl -sS https://gist.githubusercontent.com/pocki80/fc6ede395e04dde62ce2199a8281261f/raw/load_ipv6_hostsfile.sh | sudo bash

ER-showOlsrLinks-script

Installiert /usr/local/bin/links script, welches aus einem (1) beliebigen olsrd_info-plugin oder dem Routing-Table die Link-Nachbarn raussucht, je nachdem welches Plugin verfügbar ist. Abgefragt wird olsrd (IPv4) und olsrd2 (IPv6), Anzeige der Default-Route und der Anzahl an Routeneinträgen für den jeweiligen Nachbarn. Überlebt ein FW-Update, da es via post-config.d nachinstalliert wird, wenn weg. Aufruf des commands einfach mittels "links". 

 CLI> curl -sS https://gist.githubusercontent.com/pocki80/eeea81945111ac14b937bd46b83412d2/raw/install_links_script.sh | sudo bash
 CLI> links
 
 olsrd links from txtinfo_plugin
 Local IP         Remote IP          Hyst.  LQ      NLQ     Cost  #rts def?
 78.41.112.40     193.238.159.153    0.00   1.000   1.000   1.000    2 -
 78.41.112.40     78.41.112.141      0.00   1.000   1.000   1.000  486 default
 78.41.112.40     78.41.112.3        0.00   1.000   0.510   1.961    5 -
 
 olsrd2 links from nhdpinfo
 Int   Remote IPv6                         Cnt-Routes
 br0   2a02:61:0:ff:822a:a8ff:fe5f:8611      2 routes -
 br0   2a02:61:0:ff:46d9:e7ff:fe50:2a84     13 routes -
 br0   2a02:61:0:ff:feec:daff:fe4d:248f     89 routes default

ER-bootLoaderUpdateCheck-script

Prüft den aktuellen Router auf Modell, Firmware, Bootloader-Signatur und angeschlossene Geräte (PoE?). Empfiehlt gegebenenfalls das BootLoader-Update inkl. nötige Commands dafür.

Siehe https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-EdgeRouter-X-X-SFP-bootloader-update/ba-p/1472216 

 CLI> curl -sS https://gist.githubusercontent.com/pocki80/ab7e239ff78433f4ce8dec371aa0b237/raw/boot-loader-update-check.sh | bash
 
 HW model:     EdgeRouter X SFP 6-Port
 unpatched - 1 non-poe-port has a link - consider to update...
 
   curl -O https://dl.ubnt.com/firmwares/edgemax/v1.8.0/update-boot.sh
   sudo bash update-boot.sh

ER-powerCycleEthPort-script

Ab EdgeOS 1.10.5 und 2.0.0 behält der EdgeRouter-X-SFP den PoE-Zustand der Ports beim Reboot bei (beim ER-X wird PoE auf eth4 wie bisher kurz unterbrochen). Dadurch werden beim Router-Reboot die Antennen nicht mitrebootet. Um eine angesteckte Antenne mit einem einfachen CLI-Command neuzustarten, kann dieses einfache Script installiert und genutzt werden, es bleibt bei einem FW-Update auch erhalten: 

 CLI> curl -sS https://gist.githubusercontent.com/pocki80/6960085702072220ed48e1137dd5e080/raw/install_powercycle_script.sh | sudo bash
 CLI> powercycle eth4

0xFF-BMK-webstatus

Status-Seite und API für Monitoring - ist im WSLE-Wizard eingebunden

Knoten

Betreiber bzw. Tech_C folgender Funkfeuer-Knoten
wehr24
luxi122home
Abgerufen von „https://wiki.funkfeuer.at/index.php?title=Benutzer:Pocki&oldid=2877“