Die HamnetDB ist eine Wiki-artige Datenbank, mit der die Standorte, Interlinks und IP Adressen innerhalb des Hamnet verwaltet werden. Ebenfalls kann dort die Information eingetragen werden, ob ein Hamnet-Standort einen oder mehrere Benutzerzugänge anbietet. Nach einer Idee von Ralf Wilke hat Hubertus Munz seine Bachelor-Arbeit an der RWTH Aachen im Sommer 2014 abgeschlossen. In dieser implementiert er anhand von Ausbreitungsmodellen und digitalen Höhenmodellen eine Vorhersage der Funk-Abdeckung. Nun hat er in freiwilliger Weiterarbeit diese Software in die Plattform der HamnetDB eingebunden und diese dadurch erweitert. Die finale Implementierung auf dem Server von hamnetdb.net ist abgeschlossen. Die Formulare des HamnetDB zum Eintragen der Standort-Informationen wurden um die Angaben Antennendiagramm, Sendeleistung, Kabelverluste und Frequenz einheitlich erweitert. Dies ist auf dem 2. Bild zu erkennen. Ein Automatismus bemerkt Änderungen an der Datenbank und erstellt darauf hin die Abdeckungskarten neu. Als Rechner für die Simulationen wird ein am Institut für HF-Technik befindlicher 24 Core Xeon Rechner verwendet. Dieser verrringert die Rechenzeit merklich.

Als Höhendaten des Bodens wir das digitale Höhenmodel (Digital Elevation Model - DEM) ASTER Global Digital Elevation Model V002 der NASA verwendet. Daher auch folgende notwendige Deklartation: "ASTER GDEM is a product of METI and NASA."

Ein Vortrag von Ralf zu diesem Thema kann hier heruntergeladen werden. Die Amateurfunkgruppe der RWTH Aachen dankt Hubertus für seinen Einsatz.

Ebenfalls wurde auf der 60. UKW-Tagung in Weinheim eine Veröffentlichung zu diesem Thema präsentiert. Das Paper mit dem Titel "Radio Coverage Prediction for a Wireless IP-based Network in Central Europe" kann hier als PDF heruntergeladen werden. Die Folien es Vortrags gibt es hier.

Bild 1: Ansicht der Abdeckung als Beispiel mit Rundstrahlern in Krefeld und Essen

Bild 2: Erweiterung der Eingabemaske um die HF-Parameter der Benutzerzugänge

Details

Zuletzt aktualisiert: 30. September 2015

Zugriffe: 115641

Einleitung

Schon seit einigen Monaten hat sich Ralf DH3WR mit der vom Internet unabhängigen Bereitstellung von Kartenmaterial im Hamnet beschäftigt. Durch die Verfügbarkeit von neuer, leistungsfähiger Server-Hardware in Aachen kann nun dieser Dienst im zuverlässigen Produktionsbetrieb angeboten werden. Basierend auf switch2osm.org und einer Ubuntu 14.04 LTS Installation wurde ein Open Street Map Karten Server aufgesetzt.

Details zur Funktion des Kachelservers

Karten bestehen aus Teil-Bildern, die als Kacheln bezeichnet werden. Diese Kacheln werden aus dem OSM Datenbestand erzeugt. Dieser ist in einer ca. 700 GB (!) großen Datenbank auf Basis von postgresql auf einem SSD-LVM von 1,5 TB Größe gespeichert. Regemäßige Updates dieser Datenbank garantieren aktuelle Karten. Aus dieser Datenbank werden die für die jeweilige Kachel benötigten Daten ausgewählt und damit die Kachel "gemalt". Diese Daten stehen unter http://2com.db0sda.ampr.org/osm zur Verfügung. Es sind bis zur Zoomstufe 14 alle Kacheln der Welt bereits auf Vorrat erzeugt worden. Noch nicht vorhandene Kacheln werden bei Bedarf gemalt (gerendert). Damit dies in einer vertretbaren Zeit abgeschlossen ist, sind sowohl die SSDs als auch schnelle CPUs notwendig.

Struktur des verteilen Caching Clusters

Im Hamnet wird die Ladezeit einer Karte durch zwei Faktoren bestimmt:

1. Geschwindigkeit der Verbindung vom User zum Kachel-Server
2. Geschwindigkeit der Bereitstellung der Daten durch den Kachel-Server

Beide Punkte können durch einen verteilten Caching Cluster verbessert werden. Durch Zwischenspeicher-Server (caching server) wird die Last des zentralen Kachel-Server sigifikant vermindert. Viele Kacheln ändern sich nur selten und müssen daher nicht jedes Mal beim zentralen Server angefragt werden. Wenn sich dieses Konzept weiter im Hamnet verbreitet, kann durch dynamische Anpassung der Anforderungsadresse der Kacheln auch ein zum jeweiligen Nutzer nächster caching server verwendet werden. Dies steigert gleichzeitig die Reaktionszeit und senkt den Datenverkehr auf den Backbone-Linkstrecken. Als caching server wird die Software Apache Traffic Server. Dieser wird u.a. bei der Suchmaschine Yahoo! eingesetzt, wo er täglich 400 TB Daten als Lastverteiler bewegt. Damit ist diese Software als erprobt einzustufen. Das folgende Bild zeigt den aktuellen Stand des Caching Clusters im Hamnet.

Dienste und Webseiten die OSM im Hamnet nutzen

Es gibt mehrere Dienste, die Open Street Map im Hamnet benutzen.

karten.db0sda.ampr.org (Link)

Einer der zentralen Caching Server stellt eine interaktive OSM Karte bereit. Auf dieser kann ebenfalls mit einfach Werkzeugen gemalt werden. Dazu zählt das festlegen von Punkt, Linien und Flächen.

aprs.db0sda.ampr.org (Link)

Eine Kartendarstellung von APRS Postionen von Amateurfunkstationen. Diese Seite wurden von Sven Wittig dem Original aprs.fi nachempfunden. Die Positionsdatenbank auf Basis von MySQL befindet sich ebenfalls im Hamnet und wird auch über dieses mit Daten gefüllt. Den Code dazu haben Claudia Kraft und Ralf Wilke geschrieben. Insgesamt kann damit eine Echtzeitdarstellung von Positionsdaten ohne Internet-Zugang erreicht werden. Dies kann im Katastrophenfall für THW oder BOS interessant sein.

srv.db0ii.ampr.org/aprs (Link)

Diese Installtion stellt einen Klon mit Standort Mönchengladbach von aprs.db0sda.ampr.org dar. Sinn ist es, im Raum Mönchengladabach / Düsseldort einen eigenen Server für die APRS Kartendarstellung zu haben.

Aufruf zur Beteiligung am verteilten Caching Cluster

Damit diese Idee und Funktionalität im Hamnet weiter verbreitet werden, rufen wir zum Mitmachen auf. Jeder Hamnet-Knoten, der einen Linux-Server und min. 1 GB Festplattenspeicher zur Verfügung hat, kann einfach ebenfalls einen Caching Server und auf Wunsch auch eine eigene Kartendarstellung auf seiner Webseite betreiben. Die Installation ist einfach und für unerfahrende Sysops in weniger als 20 Minuten durchzuführen.

Anleitung zum Aufsetzen eines Open Street Map Proxys

1. Paket installieren

Für debian basierte Systeme:

apt-get install trafficserver

Für openSuSE: Anleitung zum selbst kompilieren

2. Konfigurieren /etc/trafficserver/storage.config

/var/cache/trafficserver 2560M

Die Größe und der Speicherort können natürlich angepasst werden.

3. Konfigurieren /etc/trafficserver/remap.config (Beispiel)

Diese Datei verbindet die Proxy-URL mit der Quell-URL. Der OSM Proxy sollte vorteilhafterweise auf Port 80 laufen. Wenn auf dem Rechner, auf dem der Proxy-Server laufen soll, auch ein Webserver auf Port 80 läuft, muss man einen Trick anwenden. Dazu stellt man in der Webserver-Config den Webserver von Port 80 auf Port 81 um. Der Traffic Server leitet dann die Anfragen, die sich nicht auf OSM beziehen, auf diesen Port um. Anfragen an xxx.ampr.org/osm werden an den Quell-Kachelserver bei DB0SDA c2com.db0sda.ampr.org weitergeleitet. Die Reihenfolge der Einträge in dieser Datei ist wichtig. Daher zuerst den "/osm" Fall abfangen und dann den allgemeinen "/" Fall. Der Ausdruck "example.db0aaa.ampr.org" ist durch den eigenen Domainnamen zu ersetzen, auf dem der Server laufen soll.

map http://example.db0aaa.ampr.org/osm/ http://c2com.db0sda.ampr.org/osm/
reverse_map http://c2com.db0sda.ampr.org/osm http://example.db0aaa.ampr.org/osm/

map http://example.db0aaa.ampr.org/ http://example.db0aaa.ampr.org:81/
reverse_map http://example.db0aaa.ampr.org:81/ http://example.db0aaa.ampr.org/

4. Konfiguration /etc/trafficserver/records.config

Hier muss der Port auf Port 80 angepasst werden.

CONFIG proxy.config.http.server_ports STRING 80

Das müssten alle notwendigen Änderungen gewesen sein. Wenn nicht, bitte bei uns kurz melden, dann berichtigen wir diese Seite.

5. (optional) Cache auf Vorat befüllen

Wir haben leider keine Möglichkeit gefunden, den Cache mit einem speziellen Kommando zu befüllen. Daher wurde ein Perl-Skript osmcache.pl geschrieben, welches dieses mittels http-Anfragen tut.

#!/usr/bin/perl
use LWP::Simple;$num_args = $#ARGV + 1;
if ($num_args != 3) {
  print "\nUsage: osmchache.pl minzoom maxzoom FQDN\n";
  exit;
}
$minzoom = $ARGV[0];
$maxzoom = $ARGV[1];


for(my $zoom = $minzoom; $zoom <= $maxzoom; $zoom++) {
  for(my $x = 0; $x <= ((4**($zoom/2))-1); $x++) {
    for(my $y = 0; $y <= ((4**($zoom/2))-1); $y++) {
      $url = "http://$ARGV[2]/osm/$zoom/$x/$y.png\n";
      get($url);
    }
  }
  print ("Zoom: $zoom fertig.\n");
}


Beispielaufruf:

sudo -u xxx nice -n 19 /usr/local/bin/osmcache.pl 1 9 proxy1.db0sda.ampr.org > /dev/null &

6. Mitteilung an RWTH AFU, dass neuer Proxy besteht

Nach erfolgreicher Installation würden wir uns über eine kurze Nachricht freuen, damit wir den neuen Proxy in den Load-Balance-Verbund aufnehmen können.

Details

Zuletzt aktualisiert: 19. Mai 2015

Zugriffe: 107363

Einleitung

Diese Anleitung soll das Aufsetzen eines Hamnet-Knotens mit OSPF beschreiben und Neuligen den Start einfacher machen. Alle Angaben nach bestem Wissen und Gewissen, aber ohne Gewähr. Die Vervielfältigung dieser Anleitung bedarf der Genehmigung des Autors. Verlinkungen werden natürlich gerne gesehen. Ein Kopieren der Bilder und Texte dieser Seite, wie ich es schon von der VPN-Anleitung gesehen habe, ist nicht gestattet.

Das Hamnet ist in Verwaltungszonen eingeteilt. Diese werden als Autonome System (AS) bezeichnet. Diese werden von der DL-IP-Koordination verwaltet. Eine Liste kann in der hamnetdb eingesehen werden.

Damit die Daten von einem AS zum anderen geleitet werden können, ist ein Routing-Protokoll notwendig. Im Hamnet hat man sich auf eBGP geeinigt. Dieses ist an allen AS-Grenzen vorgeschrieben und sorgt für Kompatibilität im Hamnet.

Innerhalb eines AS ist die Wahl des Routing-Protokolls freigestellt. Klassisch wird iBGP verwendet. Dies ist einfach zu konfigurieren und funktioniert, solange keine Schleifen oder redundante Wege innerhalb des AS sich ergeben. Im Fall des AS64634 (Aachen, Köln, Mönchengladbach) ist der Netzausbau allerdings schon so weit Fortgeschritten, dass iBGP hier an Grenzen stößt. Denn iBGP berücksichtigt nicht die Anzahl der Zwischenstationen auf einem Weg, so dass nicht immer die kürzeste Verbindung gewählt wird. Siehe auch Ankündigung OSPF Umstellung.

Karte des Autonomen Systems AS64634 (Aachen, Köln, Mönchengladbach)

Abhilfe durch OSPF

Wie der Name Open Shortest Path First schon vermuten lässt, setzt OSPF auf die Pfadlänge als Kriterium der Routenwahl. Die Kostenfunktion wird jeweils um einen Wert gehöht, je öfter ein Paket durch einen Router geleitet werden muss. Stehen also z.B. 2 redundante Pfade zur Verfügung, wird derjenige genommen, der am wenigsten Router auf seiner Strecke hat. An den AS-Grenzen muss weiterhin zu den Nachbar-AS eBGP verwendet werden. Ebenfalls müssen alle Grenz-Router zusätzlich per iBGP im Full-Mesh verbunden werden. Dadurch kann Verkehr aus Nachbar-AS auch durch das eigene AS geleitet werden. Diese Konfiguration ist aber etwas für Fortgeschrittene und wird hier zunächst nicht beschrieben.

Anleitung zum Aufsetzten eines neuen Hamnet-Knotens mit OSPF

Die folgende Anleitung soll Betreibern helfen, einen neuen Hamnet-Knoten mit OSPF zu installieren. Dabei wird angenommen, dass dieser Knoten kein Grenz-Router ist. Die Bildschirm-Fotos dienen lediglich als Beispiel und sind von der Konfiguration von DB0KX und DB0AAS entnommen. Die konkreten IP-Nummern sind der hamnetdb zu entnehmen.

1. Deaktivieren von BGP (falls vorher aktiv)

Durch Klick auf das rote Minus-Zeichen sollte man die BGP-Instanz deaktivieren, sofern sie vorher aktiv war.

2. OSPF Konfiguration öffnen

Einfach im Menu Routing -> OSPF auswählen.

3. OSPF Instanz konfigurieren

Als erstes sollte man die OSPF Instanz konfigurieren. Den Namen "default" bestehen lassen, ebenso alle anderen Einträge bis auf Router ID. Dort trägt man die IP des eigenen Routers aus dem User-Service Netz ein.

4. Eigene Subnetze publizieren

Damit die eigenen Subnetze (d.h. alle direkt erreichbaren Subnetze = lokales User/Service + Link-Subnetze) auch angepriesen werden, müssen diese einzeln unter dem Reiter "Networks" eingetragen werden. Die Vergabe eines Kommentars macht es später einfacher, die Einträge ihrer Funktion zuzuordnen.

5. Areas konfigurieren

Im Reiter Areas sind keine Änderungen zu machen. Alles kann so bleiben wie es ist.

6. OSPF Interfaces - hier: Linkstrecken

Nun muss man dem Router mitteilen, auf welchen Interfaces er OSPF sprechen soll. Ein Interface ist eine Netzwerk-Schnittstelle, also z.B. ein LAN-Anschluss oder eine WLAN-Karte, die im Router eingesteckt ist. Wir betrachten hier zunächst ein Interface, welches eine Verbindung zwischen 2 Routern darstellt.

Wichtig ist der Network Type "broadcast". Dadurch sendet der Router automatisch Broadcast Pakete, die vom gegenseitigen Router empfangen werden. So finden sich die Nachbar-Router automatisch, ohne dass etwas konfiguriert werden muss.

7. OSPF Interfaces - hier: Linkstrecken, bei denen Broadcast nicht funktioniert.

In mehreren Fällen wurde festgestellt, dass in der Broadcast-Einstellung die Verbindung zwischen den Routern nicht aufgebaut wird. Recherechen im Internet haben ergeben, dass dies an der Ubuquiti-Hardware auf dem HF-Link liegt. Diese leitet wohl die Broadcast-Pakete nicht richtig weiter. Abhilfe schafft hier die manuelle Angabe der IP des Interfaces auf dem Nachbarrouter. Dieses muss natrülich auf beiden Seiten gemacht werden. Dazu muss der Network Type auf nbma gestellt werden.

UPDATE: Wenn der Broadcast auf HF-Linkstecken nicht funktioniert, liegt das meist daran, das WDS nicht aktiviert ist.

Im Reiter "NBMA Neighbors" wird dazu für jede betroffene Link-Strecke ein neuer Eintrag angelegt. Dieser Enthält unter "Address" die IP des Nachbar-Routers aus dem Link-Subnetz. Ein Kommentar kann auch hier dafür sorgen, dass man später die Übersicht behält.

8. OSPF Anfragen auf Benutzerzugängen und dem lokalen LAN deaktiveren

Leider ist mir keine explizite Möglichkeit bekannt, OSPF auf einem Interface zu deaktivieren. Aber es gibt einen Trick. In den Interface-Eigenschaften wählt man als Network Type "point to point" und setzt den Haken bei "Passive". Dadurch unternimmt der Router auf diesem Interface keine Anstalten, einen OSPF-Nachbarn zu suchen.

9. Kontrolle der OSPF-Verbindungen

Um seine Arbeit zu überprüfen, kann man unter dem Reiter Neighors die aufgebauten OSPF-Verbindungen überprüfen.

Details

Zuletzt aktualisiert: 15. August 2016

Zugriffe: 110629

Als zentrale Ablage und zum Verteilen von Dateien wurde an der Amateurfunkstation der RWTH Aachen ein Cloud-Server installiert. Basierend auf dem System OwnCloud wurde einer der Server mit diesem System ausgestattet. Der Zugriff geschieht in erster Linie über das Web-Interface; es gibt aber auch Hilfsprogramm für Desktop-PCs und mobile Endgeräte auf Android und iOS Basis. Zur Zeit stehen ca 3 TB Speicherplatz zur Verfügung. Wer einen Benutzer-Zugang haben möchte, schreibe uns einfach eine Email. Der Zugriff ist zunächst nur aus dem Hamnet möglich, evtl. werden wir auch das Internet erlauben. Der Speicherplatz pro Benutzer ist nominell 10 GB, kann aber auf Anfrage und Begründung erhöht werden.

Zugriff auf die AfuCloud über http://db0sda.ampr.org/owncloud.

Bildschirmfoto als Appetitanreger

Details

Zuletzt aktualisiert: 20. März 2017

Zugriffe: 92335