<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hallo HamNet_V - ML,<br>
<br>
zunächst möchte ich Dirk, DG0KF
& SysOp DB0HGW, DB0OVP recht herzlich in der Mailinglist für
HAMNET im Distrikt V begrüßen.. Er plant an seinem Standort eine
HAMNET-Backbone - Infrastruktur aufzubauen und wand sich mit
seinem Anliegen an mich, um den aktuellen Status zu HAMNET in
unserem Distrikt zu erfragen.. Damit alle Listen-Mitglieder die
vorangegangene Diskussion zwischen Dirk und mir verfolgen können
und auch eigene Kommentare abgeben können, habe ich mir erlaubt
das Gespräch in die Mailinglist zu verlagern.. Es ist sehr zu
begrüßen, daß wohl nun endlich mit der Umsetzung zur Errichtung
einer HAMNET-Backbone-Infrastruktur in unserem Distrikt begonnen
wird, nachdem ich vor Jahren beim ANIR (hier war es Thomas,
DL9SAU, vom AMPR-IP-Koordinatorenteam, welcher uns die bis heute
gültige ASN mit den entsprechenden IP-Blöcken zuwies) ein Subnet
für unseren Distrikt beantragte und die Planungen für den
Netzausbau vornahm..<br>
<br>
Wenn HAMNET jetzt also auch im Nordosten Deutschlands starten
soll, müssen die nächsten Schritte wohl überlegt sein.. Damit
später kein bunter Mix an unterschiedlicher Hardware- und
Softwarekonfiguration entsteht, sollten wir uns auf einige
Standards einigen, welche in unserem Distrikt Gültigkeit haben,
aber uns gleichzeitig auch an die Vorgaben halten, die vom ANIR
gefordert werden.. Mit diesen von uns festgelegten Standard wird
uns eine gewisse Einheitlichkeit garantiert, was besonders
hilfreich ist, da sonst ein Durcheinander an verschiedenen
Hardware-Plattformen existieren würde und man sich in neue
Hardware erst hineindenken müßte.. Wenn wir uns auf zwei oder
maximal drei Herstellerfirmen von WLAN-Plattformen einigen, wüßte
jeder OM um die Besonderheiten dieser Hardware und etwas mit den
Begriffen "NanoBridge", "Loco", "RB" etc. anzufangen..<br>
Deshalb schlage ich vor in unserem Distrikt für die Verwendung im
HAMNET-Backbone nur Hardware der Hersteller<br>
<br>
* Mikrotik<br>
* Ubiquiti<br>
* Gateworks<br>
<br>
zu verwenden, wobei jede der Plattform spezifische Besonderheiten
hat, welche jeder HAMNET-SysOp kennen sollte.. Hardware von
Mikrotik zum Beispiel stellt kleine Einplatinen-Computer her,
welche meistens mehrere mini-PCI - Erweiterungsslots und eine oder
mehrere Ethernetbuchsen aufweisen.. In die mini-PCI - Slots werden
dann die WLAN-Karten gesteckt.. Mit sog. Pigtails (engl. für
Schweineschwanz, Ringelschwanz bei Schweinen), einem Koaxkabel,
wird die WLAN-Karte mit einer N-Buchse, welche im Gehäuse
befestigt wird, in welchem auch das Mikrotik-Board verbaut ist,
verbunden.. Diese Hardware-Konfiguration erlaubt die Installation
eigens ausgewählter Antennen wie z.B. Planar-, Spiegel-, Sektor-
oder Rundstrahlantennen oder den Bau ganz eigener
Antennengebilde.. Weil der Amateurfunkdienst ja ein
experimenteller Funkdienst ist, kann man hier recht gut mit
Frequenzen, Sendeleistungen und Antennen experimentieren..
Mikrotik findet vielfach im Süden Deutschlands Verwendung..<br>
<br>
Aber auch Hardware von Ubiquiti hat einige Vorzüge.. Damals
stellte die amerikanische Firma genau wie heute noch Mikrotik
entsprechende Boards für den WLAN-Einsatz her, die unter dem Namen
NanoStation (NS) und NanoStation Pro (NS Pro) vertrieben wurden..
Heute ist Ubiquiti zu kompakter Hardware in MIMO-Technik
übergegangen.. So ist das Board und die Antenne in einem Gehäuse
integriert.. Es gibt verschiedene Ausführungen.. Die Bullet zum
Beispiel ist im Grunde nur ein Stück Plastikrohr, daß es in sich
hat.. Am einen Ende des Rohrs ist eine Ethernet-Buchse verbaut,
während sich auf der anderen eine N-Buchse befindet.. Zwischen
diesen beiden Buchsen ist im Rohr der eigentliche Accesspoint
verbaut.. Das Bullet wird meist in Verbindung mit
Rundstrahlantennen benutzt, aber auch auch Gitterantennen.. Die
Installation ist einfach.. Bullet auf die HF-Einspeisung der
Rundstrahlantenne oder des Erregerelements der Grid schrauben und
Ethernetkabel in die Ethernetbuchse am anderen Ende des Stücks
Rohrs stecken.. Fertig!!<br>
Ähnlich funktioniert das mit der Bridge.. Sie besteht aus einem
Spiegel, einer Aufnahme für den Accesspoint (AP) und dem AP
selbst, welcher wiederum aus Board und Antenne in einem Gehäuse
integriert besteht.. Auch hier ist die Installation sehr einfach..
Aufnahme mit Schrauben im Spiegel befestigen, AP in die Aufnahme
stecken und Spiegel am Mast befestigen.. Die Bridge ist darauf
ausgelegt, zwei WLAN-Standorte miteinander zu verbinden und hohe,
weil in MIMO-Technik aufgebaut, Datenraten zu übertragen..<br>
Die Loco ist ein sehr kleiner AP zur Mast-Montage.. Sie eignet
sich zur Installation bei HAMNET-Nutzern, welche im HAMNET surfen
möchten.. Auch hier ist Board und Antenne in einem Gehäuse
untergebracht.. Die Loco gibt es für 13cm (Loco M2) und 6cm (Loco
M5)..<br>
Praktisch bei Ubiquiti ist die in den Geräten eingebaute grobe
Feldstärkeanzeige, die während des Bootens den Status den AP
anzeigt.. Die Signalstärke, bei welcher Feldstärke bestimmte LEDs
eingeschaltet werden, läßt sich beliebig einstellen, genauso
welcher Status über die LEDs angezeigt werden soll.. Sehr
Vorteilhaft bei Ubiquiti-Geräten ist auch die Kürze der
Antennenzuleitung zur Antenne, da meistens schon im Gerät
integriert.. Damit entfällt das handtieren mit zusätzlichen
Antennen und Leitungsverluste werden minimiert.. Im freien Funknet
(Freifunk) der Opennet-Initiative e.V. in Rostock wird seit
einigen Jahren im Rahmen der Umrüstung auf Ubiquiti vielfach auf
diese Hardware zurückgegriffen.. Fast der gesamte Backbone ist mit
Ubiquiti NanoBridges aufgebaut und auch viele der "Kunden" im
Opennet verwenden Ubiquiti Loco für den Zugriff auf dieses MAN..<br>
Aber Hardware von Ubiquiti hat neben all diesen Vorzügen auch
einen Nachteil: Im Sinne des Amateurfunks mit WLAN-Experimentieren
ist dann nicht mehr viel, da alles auf Plug&Play getrimmt ist
- aufbauen und loslegen..<br>
<br>
Für SysOp's, die einen großen Knotenpunkt aufbauen möchten und auf
sehr leistungsfähige Hardware zurückgereifen müssen, wäre Hardware
von Gateworks interessant.. Praktisch ist die Anzahl von gleich
vier mini-PCI - Steckplätzen auf einem Board bei Avila.. So könnte
man mit nur einem AP Backbone-Verbindungen in alle vier
Himmelsrichtungen aufbauen oder einen Usereinstieg mit vier
Sektorantennen realisieren.. Und da schnelle Hardware zum Einsatz
kommt, ließen sich auch einige Server-Prozesse auf einem solchen
Board betreiben.. Gegenüber der Hardware der anderen beiden
genannten Hersteller ist Hardware von Gateworks allerdings sehr
teuer..<br>
<br>
Bei den WLAN-Karten sollten wir ausschließlich die "Wistron
DCMA-82" verwenden.. Sie genügt allen für unsere Zwecke
erforderlichen Maßgaben und sollte als DIE Standard-WLAN-Karte für
HAMNET auch in unserem Distrikt eingesetzt werden..<br>
<br>
Welche Hardware Ihr für Euren Standort verwenden wollt, hängt also
davon ab, welchen Zweck die Installation erfüllen soll.. Der SysOp
hat da volle Entscheidungsfreiheit, nur sollte man bedenken, daß
wenn andere Plattformen verwendet werden und es tritt ein Problem
auf man ziemlich alleine da steht und sich um eine Lösung bemüht..
Sicher schadet es aber nicht, sich mit dem SysOp des
Nachbar-Standortes abzustimmen oder an die ML zu schreiben..<br>
<br>
<br>
<br>
<br>
Auch bei der Software gelten einige Vorgaben, welche wir einhalten
sollten.. Diese Vorgaben wurden einmal vom ANIR festgelegt, andere
lege ich als ARIR für unseren Distrikt fest, damit nicht nur
Backbone-Verbindungen zwischen den HAMNET-Standorten aufgebaut
werden können, sondern auch die Integration unseres HAMNET in das
bereits bestehende HAMNET problemlos möglich ist.. Da diese Punkte
besonders wichtig sind, führe ich diese zunächst in einer kurzen
Übersichtsliste auf und erläutere diese mit mehr oder weniger
kurzen Kommentaren in darunterliegenden Absätzen..<br>
<br>
Hier die Liste mit den Standards:<br>
<br>
* Einhaltung der Koordinatoren-Hierarchie<br>
* Routingprotokoll: OSPF (für distriktsinterne
Backbone-Verbindungen)<br>
eBGP (für Backbone-Verbindungen zum
Nachbar-Distrikt)<br>
* einen BGP-Konzentrator und einen DNS-Server<br>
* Tunnel ins HAMNET<br>
* strikte Trennung zwischen Backbone und User/Service<br>
* keine Multipoint-BB-Verbindungen<br>
* Passwort für SysOp und ARIR<br>
* IPv6-Support<br>
* Backbone-Verbindungen auf 3 GHz und/oder 5GHz<br>
* ESSID und DNS<br>
<br>
<br>
Nun die Punkte im Einzelnen:<br>
* Einhaltung der Koordinatoren-Hierarchie<br>
In Hinblick auf die spätere Entwicklung bzw. Endausbaus des HAMNET
sollten unbedingt die Hierarchien bei den Ansprechpartner
eingehalten werden.. Daran sollte sich schon heute gehalten
werden.. Sicher wird es Thomas, DL9SAU, als Mitglied im
AMPR-IP-Koordinatoren-Team (ANIR), zuständig für HAMNET im Osten
Deutschlands, nicht gefallen, wenn er täglich hunderte von
eMail-Anfragen bezüglich HAMNET erhält, welche zumeist belanglose
Dinge enthalten, weil ein OM keine HAMNET-Verbindung zum lokalen
HAMNET-Standort aufbauen kann.. Zumal kann Thomas von der Ferne
sowieso wenig ausrichten, weil er weder die Situationen noch die
Ansprechpartner kennt.. Damit eMail-Postfächer nicht gefloodet
werden, bitte ich alle hier mitlesenden OM's sich an die
Hierarchien zu halten.. Dabei kontaktieren OM's, die im HAMNET
surfen, bei Problemen zunächst den SysOp des Standortes, bei
welchem sich die HAMNET-Nutzer sich einloggen.. Oftmals kann der
SysOp da schon weiterhelfen, indem gemeinsam eine Lösung
erarbeitet wird.. Oder andere Nutzer helfen bei einem Problem aus,
was ja durchaus der Fall sein kann, wenn der SysOp z.B. durch QRL
u.ä. nicht sofort erreichbar ist.. HamSpirit - wir sind alle
Funkamateure und helfen uns gegenseitig..<br>
Es kann aber auch schonmal vorkommen, daß der SysOp des jeweiligen
Standortes selbst ein Problem hat (z.B. Routingfehler im Backbone,
oder Zuteilung von IP-Adressen etc.) oder bei einem Problem mit
einem Nutzer überfragt ist.. Dann kann der ARIR des jeweiligen
Distriktes (in unserem Distrikt DL7RAY) sicher aushelfen.. Auch
wenn es um Netzplanung, neue Standards oder HAMNET-Treffen geht,
kurz um, wenn es um allgemeine Dinge, welche im gesamten HAMNET
des Distriktes Gültigkeit haben, bin ich der richtige
Ansprechpartner.. Wenn ein Nutzer einen HAMNET-Dienst betreiben
möchte (z.B. WebCam, WX-Station, http-Server etc.), sollte er
diesen Wunsch seinem SysOp melden.. Der SysOp weiß, daß für die
ständige Erreichbarkeit eine feste IP-Adresse erforderlich ist und
fragt beim ARIR nach einer zu vergebenden IP-Adresse.. Der ARIR
trägt die zu vergebene IP in eine Liste ein (Registration) und
teilt die zugeteilte IP dem anfragen SysOp weiter, welcher diese
an den Nutzer weiter reicht..<br>
Ideen und Wünsche von Nutzern und SysOps aus unserem Distrikt,
welche ich auch nicht beantworten kann, leite ich an DL9SAU
weiter.. So bekommt Thomas nur die wirklich wichtigen Anfragen,
über welche er ggf. mit den anderen ANIR abstimmen muß (z.B. wenn
das Thema IPv6 wieder aufgegriffen wird).. Zusätzlich ließt er
aber auch in dieser Liste mit.. Fragen, die ich zu Thomas
weiterleiten muß wären zum Beispiel jene, die mit der Vergabe
neuer Subnetze einhergehen, Tunnel von unserem Distrikt zum
Ost-Hub oder bei Fragen, bei denen ich selbst überfragt bin..<br>
Außerdem kann jeder OM in diese Liste schreiben, der nach einer
Lösung für sein Problem bei HAMNET sucht.. So stelle ich mir
reibungslose Kommunikation vor, ohne dabei die Postfächer
wichtiger OM's mit "Spam" 'zuzumüllen'..<br>
<br>
* Routingprotokoll:<br>
Für das Routing im Backbone des Distriktes V wird OSPF
eingesetzt.. Damit wird Distriktsintern nur ein Routingprotokoll
eingesetzt, was in Hinblick auf die spätere Backbone-Infrastruktur
in unserem Distrikt flexibel und leistungsfähig genug ist, die
verschiedenen HAMNET-Standorte zu verwalten, ohne daß uns die
ganze Sache mit HAMNET über den Kopf wächst.. Bei den sog.
Border-Gateways kommt ein zusätzliches Routingprotokoll zum
Einsatz.. Bordergateways sind HAMNET-Standorte an unseren
Distriktsgrenzen, welche eine Backbone-Verbindung zum
Nachbardistrikt haben.. Über diese Backbone-Verbindung zum
Nachbardistrikt wird eBGP (external BorderGatewayProtocol)
eingesetzt, um Routinginformationen zum Nachbardistrikt
austauschen zu können.. Für unseren Fall wären dies die Standorte
DB0NBB <-> DB0ZEH und DB0KUE <-> DB0MAR, aber auch
Tunnel..<br>
<br>
* BGP-Konzentrator und DNS-Server<br>
Sehr Vorteilhaft wäre die Einrichtung eines BGP-Kenzentrator und
DNS-Servers am Standort von DB0HST in Stralsund, da sich dieser
potentielle HAMNET-Standort auf dem Campus-Gelände der
Fachhochschule Stralsund befindet und damit ein möglicher Zugang
zum DFN bereitsteht..<br>
<br>
* Tunnel ins HAMNET<br>
Da per WLAN noch keine Verbindung zum bereits bestehenden HAMNET
aufgebaut werden kann, sind wir für die Dauer, in der unser
Distrikt noch nicht am HAMNET angebunden ist, auf einen Tunnel
angewiesen.. Dieser Tunnel sollte von dem HAMNET-Standort, der am
Dichtesten zu einem HAMNET-Standort des Nachbar-Distriktes steht,
eingerichtet werden.. So könnte man DB0NBB per Tunnel an den
Ost-Hub anschließen und einen Backbone-Link zu DB0HGW und DB0OVP
bauen, womit die erste HAMNET-Insel in unserem Distrikt am HAMNET
angeschlossen wäre.. Trotzdem sollte eine Devise oberste Priorität
haben: "So wenig Tunnel wie möglich, so
viel wie nötig".. Damit behält man den Überblick über die aktiven
Tunnel, ohne Gefahr zu laufen, daß Tunnel kreuz und quer durch das
gesamte Bundesgebiet verlaufen.. Zudem soll das HAMNET auch dann
noch sicher funktionieren, wenn alle anderen Kommunikationsmittel
ihren Dienst versagen; also auch selbst dann, wenn das Internet
weg bricht.. Das HAMNET soll autark funktionieren, ohne
irgendwelche Tunnellösungen..<br>
<br>
* strikte Trennung zwischen Backbone und User/Service<br>
Für das Backbone-Netz und für die Verwendung als User/Service gibt
es getrennte IP-Adressen.. Diese beiden Netze sollen auch
weiterhin getrennt bleiben.. Es gilt der Grundsatz, daß alle
Hosts, die unmittelbar im HAMNET-Backbone hängen, auch IP-Adressen
speziell für den Backbone erhalten.. Alle anderen Dienste (z.B.
Webserver, WebCam, Fonie-Relais, PR, APRS, WX etc.) und Nutzer
(OM's, die im HAMNET surfen), erhalten einen kleinen IP-Pool
(DHCP-Server der HAMNET-Standorte für User-Login) oder jeweils
eine IP-Adresse für einen Host, der von außen zugänglich sein
muß.. Wenn DB0HGW / DB0OVP eingerichtet ist, kann man sich diesen
als Vorbild nehmen und nach diesem Beispiel auch die anderen
HAMNET-Standorte einrichten..<br>
<br>
* keine Multipoint-BB-Verbindungen<br>
Wir sollten es vermeiden im Backbone Multipoint-Verbindungen
herzustellen, da sonst der Datendurchsatz durch ständige
automatische Änderung des Routings leiden würde..
Multipoint-Verbindungen sind Verbindungen, welche von einem
HAMNET-Standort zu mehreren HAMNET-Standorten führen.. Stattdessen
sollten wir für jeden Backbone-Link genau eine Gegenstelle haben,
mit der sich dieser BB-AP verbindet.. Auf den
HAMNET-Usereinstiegen sind Multipoint-Verbindungen erwünscht..
Aber wenn die Datenrate auf dem Usereinstieg stockt, muß an diesem
HAMNET-Standort möglicherweise ein zweiter Usereinstieg
eingerichtet werden..<br>
<br>
* Passwort für SysOp und ARIR<br>
Damit niemand unbefugt an der Konfiguration der einzelnen
HAMNET-Devices herumspielt, sollten alle Geräte mit einem Passwort
versehen werden.. Befugt sind die SysOps des jeweiligen
HAMNET-Standortes und der ARIR.. Warum soll der ARIR auch
autorisiert sein Änderungen an der Konfiguration vornehmen zu
dürfen?! Weil der ARIR den Überblick über das gesamte HAMNET des
Distriktes hat und so schneller Rückschlüsse auf
Fehlkonfigurationen ziehen kann.. So kann er bei Meldung eines
Problems direkt eingreifen und schnell zur Lösung beitragen.. Der
jeweilige SysOp erhält eine eMail über die vom ARIR gemachten
Einstellungen, sodaß der SysOp informiert ist und es dadurch
vermieden wird, alte Einstellungen zurückzuschreiben.. Ich schlage
vor, für den Login des SysOps ganz normal den root-Account
(root:root) zu verwenden und für den Login des ARIR einen neuen
User 'arir' in der Gruppe 'root' mit root-Rechten anzulegen
(arir:root).. Damit kann der SysOp auch nachvollziehen, wenn sich
der ARIR eingeloggt hat und welche Eingaben gemacht worden sind..<br>
<br>
* IPv6-Support<br>
Im Distrikt V sollte jeder HAMNET-AP das Internet-Protokoll
Version 6 unterstützen.. Ich denke, daß IPv6 im HAMNET irgendwann
enorm wichtig werden wird und da möchten wir schon jetzt
vorbereitet sein.. Zwar wird im HAMNET überwiegend noch mit dem
alten Internet-Protokoll (IPv4) gearbeitet, aber für Experimente
im HAMNET läßt sich IPv6 durchaus anwenden.. Zur Zeit ist aber imo
IPv6 im HAMNET noch nicht im Einsatz..<br>
@DL9SAU: Thomas, weißt Du, ob Brian für 44.0.0.0/8 bereits ein
IPv6-Subnet beantragt hat (z.B.: fd2c::/16)?!<br>
<br>
* Backbone-Verbindungen auf 3 GHz und/oder 5GHz<br>
Vorzugweise sollten Backbone-Verbindungen auf den höheren Bändern
abgewickelt werden.. Hier ist das Störaufkommen nicht so hoch wie
bei 2.4GHz, wo viele WLAN-Geräte von Nutzern senden..<br>
<br>
* ESSID und DNS<br>
Auch wir sollten die vom ANIR vorgeschlagene Struktur bei der
Namensvergabe verwenden.. Hier ein Beispiel:<br>
<br>
link-hgw-nbb.db0hgw.as64642.de.ampr.org<br>
<br>
Dabei liegt folgende Struktur zugrunde:<br>
.ampr.org = DOMAINNAME für das internationale AMPRNET
(44.0.0.0/8)<br>
.de = COUNTRY im AMPRNET (ermöglicht echte Delegation
im Internet!)<br>
.as64642 = ZONENAME eines AS (Unterscheidung der verschiedenen
AS-Zonen) Unser Distrikt hat die ASN 64642<br>
.db0hgw = CALLSIGN vom jeweiligen STANDORT innerhalb des AS<br>
link-hgw-nbb = HOSTNAME für ein Gerät, einen Dienst, Router, eine
IP-Steckdose etc.<br>
<br>
Auch wir sollten diese Struktur beibehalten.. Hier werde ich
später mehr Zeilen schreiben, aber ich denke das Prinzip ist
klar..<br>
<br>
<br>
Wenn wir uns an all diese Regeln halten, sollte einem
funktionierenden HAMNET eigentlich nichts mehr im Wege stehen..
HAMNET ist das, was ein jeder SysOp daraus macht.. Je besser die
Konfiguration, desto besser wird man im HAMNET auch surfen können
und desto störungsfreier ist der spätere Betrieb, wenn auch die
einzelnen Repeaterstandorte vernetzt sein werden.. Darum laßt uns
gemeinsam alle anpacken und uns ein schönes Backbone-Netz nach dem
Muster auf <a class="moz-txt-link-abbreviated" href="http://www.hamnet-dl.de/">www.hamnet-dl.de/</a> aufbauen.. <br>
<br>
73 de Bjørn, DL7RAY & SysOp DB0HRO & ARIR Distrikt V<br>
<br>
<br>
Am 26.08.2012 23:04, schrieb Dirk:<br>
</div>
<blockquote cite="mid:503A8F54.6020700@gmx.de" type="cite">Hallo
Bjørn,
<br>
<br>
Vielen Dank, für Deine ausführlichen Informationen. Das war eine
Menge Stoff zum lesen.
<br>
<br>
Zu einigen Punkten die du angesprochen hast.
<br>
<br>
Die Karte des geplanten Netzes hatte ich auch im Internet
gefunden.
<br>
Für die Verbindung HGW <->HST sehe ich auch keine Probleme,
laut Streckenprofil sollte es
<br>
gehen. Berechnung sieht i.O. aus. Bei der Strecke NBB <->
HGW sieht es schon anders
<br>
aus. Das Streckenprofil sagt es geht nicht. Vor NBB ist laut
Profil ein Berg wo wir nicht drüber
<br>
kommen. In Natura habe ich diesen Berg allerdings noch nicht
gefunden. Ohne Berg ist die
<br>
Berechnung noch i.O. aber nur mit hohem Antennengewinn. Da ist auf
jeden Fall noch Klärungs-
<br>
bedarf.
<br>
</blockquote>
Ich habe die Höhen der Antennen über Grund neu festgesetzt.. So
befindet sich die Höhe der Antenne über Grund bei DB0HGW bei 75
Metern.. Diese Höhe habe ich aus dem Internet für die Bakenantenne
entnommen.. Auf welche Höhe sich die HAMNET-Antenne befinden wird,
weiß ich nicht.. Die Höhe der HAMNET-Antenne bei DB0NBB habe mit 8o
Metern bei DB0NBB willkürlich gewählt.. Hier fehlt mir eine genaue
Antennen- bzw. Plattformhöhe.. Wenn etwas mehr als die Hälfte der
Ausdehnung des Fresnelzone verfügbar ist, sollte eine Verbindung mit
guten Antennen möglich sein.. Gerade für den Backbone-Link zwischen
DB0HGW und DB0NBB sollten Antennen mit gutem Gewinn zum Einsatz
kommen.. Hier mal ein Vorschlag, aus welchen Komponenten ein BB-Node
bestehen könnte:<br>
<br>
<pre><i> Anzahl | Bezeichnung | Produktname | Preis | URL zum Produkt
</i><i> -------|---------------|---------------------------|-----------|---------------------------------------------------------------------------------------------------------
</i><i> 1x | Routergehäuse | PC Engines Outdoor Gehäuse| 48,58 EUR | <a href="http://www.mikrotik-shop.de/Gehaeuse/Outdoor/PC-Engines-Outdoor-Gehaeuse-1x-N-Typ-1x-Ethernet::267.html">http://www.mikrotik-shop.de/Gehaeuse/Outdoor/PC-Engines-Outdoor-Gehaeuse-1x-N-Typ-1x-Ethernet::267.html</a>
</i><i> 1x | Montageplatte | für MikroTik-Routerboard | 17,50 EUR | <a href="http://www.mikrotik-shop.de/Gehaeuse/Outdoor/Montageplatte-MikroTik::271.html">http://www.mikrotik-shop.de/Gehaeuse/Outdoor/Montageplatte-MikroTik::271.html</a>
</i><i> 1x | Routerboard | MikroTik RB411AH | 71,36 EUR | <a href="http://www.mikrotik-shop.de/Mainboards/MikroTik-RouterBOARD-411AH-L4-1-x-LAN-1-x-miniPCI::234.html">http://www.mikrotik-shop.de/Mainboards/MikroTik-RouterBOARD-411AH-L4-1-x-LAN-1-x-miniPCI::234.html</a>
</i><i> 1x | WLAN-Iface | Wistron DCMA-82 | 38,00 EUR | <a href="http://www.mikrotik-shop.de/Interfaces/Wistron-DCMA82::276.html">http://www.mikrotik-shop.de/Interfaces/Wistron-DCMA82::276.html</a>
</i><i> 1x | Pigtail | HDF-100, MMCX -> Type-N | 7,50 EUR | <a href="http://www.mikrotik-shop.de/Antennenkabel/Pigtails/18cm-Pigtail-MMCX-auf-N-Buchse::300.html">http://www.mikrotik-shop.de/Antennenkabel/Pigtails/18cm-Pigtail-MMCX-auf-N-Buchse::300.html</a>
</i><i> 25 cm | Koaxkabel | Ecoflex 15 Plus / Meter | 10,95 EUR | <a href="http://www.conrad.de/ce/de/product/604980/KOAXIALKABEL-SCHWARZ-ECOFLEX-15-PLUS">http://www.conrad.de/ce/de/product/604980/KOAXIALKABEL-SCHWARZ-ECOFLEX-15-PLUS</a>
</i><i> 2x | HF-Steckverb. | Type-N Stecker | 9,90 EUR | <a href="http://www.mega-kom.de/eshop/product_info.php?products_id=12098">http://www.mega-kom.de/eshop/product_info.php?products_id=12098</a>
</i><i> 1x | Antenne | PARABOLA XP 36 dBi, 5 GHz | 96,60 EUR | <a href="http://www.atel-electronics.eu/produkt.php?hash=05225&dispLang=EN">http://www.atel-electronics.eu/produkt.php?hash=05225&dispLang=EN</a>
</i><i> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
</i><i> 310,29 EUR</i>
</pre>
<br>
<blockquote cite="mid:503A8F54.6020700@gmx.de" type="cite">
<br>
Bei den Admin - Rechten für die eingesetzte Geräte sehe ich keine
Probleme. Im PR-Netz war es
<br>
zumindest bei DB0HGW ähnlich. Da hatten auch mehrere OM´s die
Möglichkeit Systemparameter
<br>
anzupassen.
<br>
</blockquote>
So sollte das auch im HAMNET sein, wobei man genau überlegen sollte,
wer root-Rechte bekommt, denn mit diesen erhält man ALLE Rechte zur
Konfiguration des jeweiligen Device..<br>
<blockquote cite="mid:503A8F54.6020700@gmx.de" type="cite">
<br>
An dem Block Bild der geplanten Stationen bin ich dran.
<br>
</blockquote>
Sehr schön.. So bekommt man gleich einen optischen Eindruck über den
Aufbau.. Das Programm "dia" kann ich Dir für solche Dinge sehr
empfehlen..<br>
<blockquote cite="mid:503A8F54.6020700@gmx.de" type="cite">
<br>
Es ist aber auch nicht kompliziert was wir hier vorhaben.
<br>
<br>
DB0HGW : Standort Greifswalder DOM dort laufen alle
HF-Verbindungen Links / Einstiege,
<br>
D-Star Repeater (beantragt), APRS , (geplant
Anbindung Echolink, Klubstation, Usereinstieg)
<br>
<br>
DB0OVP: Standort: Gahlkow (bei mir zu Hause) dort laufen
DX-Cluster, Internet-Verbindungen
<br>
<br>
DB0HGW und DB0OVP sind mit einem HF-Link verbunden. Bis jetzt lief
der Link im 23cm -Band
<br>
mit der zur Zeit beantragten Lizenzverlängerung habe ich eine
Frequenz im 6cm Band mit HamNet-
<br>
Parametern beantragt.
<br>
Ein Linktest auf der Strecke (12km) mit grob ausgerichteten Nano
Bridge´s, hat gute Ergebnisse gebracht.<br>
</blockquote>
Das würde mich auch schwer wundern, wenn es mit NB über eine Distanz
von ~1o km nicht funktionieren sollte.. ;-)<br>
<blockquote cite="mid:503A8F54.6020700@gmx.de" type="cite">Da wären
wir beim nächsten Punkt.
<br>
<br>
Der VPN-Tunnel zum HamNet. Aus Erfahrung der letzten Jahre werde
ich das DX-Cluster auch weiter
<br>
direkt am Internet betreiben bzw. mich nicht mehr nur auf HF-Links
verlassen. Es sollten natürlich vorrangig
<br>
die HF-Links genutzt werden, wie es die PR-Technik auch schon
gemacht hat. Aber als Backup sollte ein
<br>
VPN-Tunnel verfügbar sein. Dieser könnte dann auch von DB0OVP
ausgehen.
<br>
</blockquote>
Tunnel sollten sparsam verwendet werden.. Begründung siehe oben..<br>
<blockquote cite="mid:503A8F54.6020700@gmx.de" type="cite">
<br>
Beim Routing Protokoll sollten wir das nehmen was für uns
zukünftig besser ist. Ich denke da hast du mehr
<br>
Erfahrung.
<br>
<br>
Bleibt noch die Frage der zu verwendeten Hardware.
<br>
Ich habe gelesen das im Süden größtenteils die Routerboards von
Mikrotik eingesetzt werden bzw. die
<br>
Nano Station/Bridge von ubnt. Gibt es dort bei uns schon
Erfahrungen oder Absprachen?
<br>
</blockquote>
Absprachen gibt es bisher zwar noch nicht, aber wir sollten auf die
o.a. Hardware zurückgreifen.. Erfahrungen habe ich schon mit allen
dreien Plattformen und einigen weiteren gemacht.. Wie es bei den
anderen hier mitlesenden OM's aussieht kann ich leider nicht sagen..
Aber vielleicht kann man für die Wintermonate mal wieder ein
HAMNET-Kompetenz-Treffen machen..<br>
<blockquote cite="mid:503A8F54.6020700@gmx.de" type="cite">
<br>
Auf den Mailverteiler habe ich mich eingetragen.
<br>
</blockquote>
Das habe ich gelesen.. Das ist aber schon eine kleine Weile her..
:-D<br>
<blockquote cite="mid:503A8F54.6020700@gmx.de" type="cite">
<br>
vy 73
<br>
<br>
Dirk, DG0KF
<br>
<br>
<br>
Am 17.08.2012 01:55, schrieb Bjørn Kagelmacher:
<br>
<blockquote type="cite">Hallo Dirk,
<br>
es freut mich, daß es nun wohl erstmals mit HAMNET in unserem
Distrikt
<br>
vorangehen wird.. Schön, wenn es klappt ein lauffähiges HAMNET
vorweisen
<br>
zu können..
<br>
<br>
Seit dem Treffen vor 2 Jahren ist leider noch nichts bezüglich
der
<br>
Realisierung eines HAMNET im Distrikt V passiert.. Es fehlt wie
so oft
<br>
!!ein Anfang!!, wo andere SysOps und OM's sehen, daß HAMNET nun
auch in
<br>
unserem Distrikt startet und
<br>
sich mit ihrer WLAN-Technik an ein bereits bestehendes HAMNET
verbinden
<br>
(assoziieren) und an Know-How anknüpfen können.. Dieses Treffen
sollte
<br>
allen teilnehmenden OM's Mut machen, ein HAMNET aufzubauen und
auch Wege
<br>
aufzeigen, wie eine Lösung aussehen könnte..
<br>
<br>
Zwischenzeitlich hatte ich einige Anfragen bezüglich des
<br>
Aufbaufortschritts des HAMNET in unserem Distrikt erhalten,
welcher die
<br>
Dokumentation auf <a class="moz-txt-link-abbreviated" href="http://www.hamnet-dl.de/">www.hamnet-dl.de/</a> zur Grundlage hatte.. Leider
wurde
<br>
die Zeichnung so interpretiert,
<br>
als würde das HAMNET bereits fertig aufgebaut bestehen und ich
wurde
<br>
gefragt wie man daran teilnehmen kann.. So mußte ich den
interessierten
<br>
OM's erklären, daß es sich bei dieser Zeichnung nur um einen
Entwurf
<br>
handelt, wie das Backbone-Netz später einmal aussehen soll..
Dies ist
<br>
auch daran zu erkennen, daß keiner der Standorte eine
vollständige
<br>
IP-Adresse hat.. Diese wird bei der Aktivierung des Standortes
vom ARIR
<br>
vergeben.. Außerdem hatte der Ortsverband Greifswald die Idee
ihre
<br>
Clubräume via DB0MAR (Timmendorfer Strand) an das HAMNET
anzubinden..
<br>
Dazu sollte eine Ubiquiti NS auf dem Fernmeldemast des OV
installiert
<br>
werden, was allerdings wieder etwas eingeschlafen ist.. Schön,
wenn in
<br>
Grevesmühlen ein HAMNET-Client in Betrieb geht; aber eigentlich
geht es
<br>
mir als ARIR des Distriktes V vorrangig um den Aufbau einer
<br>
HAMNET-Backbone-Infrastruktur.. Mit DB0HGW bzw. DB0OVP wären die
ersten
<br>
automatischen Funkstellen in unserem Distrikt mit
HAMNET-Unterstützung
<br>
in Betrieb..
<br>
<br>
Warum das so lange mit dem Aufbau eines HAMNET in unserem
Distrikt auf
<br>
sich warten läßt, kann ich mir nur so erklären, daß die für den
<br>
jeweiligen Standort zuständigen SysOps die Anschaffungskosten,
oder die
<br>
für sie noch recht neue Technik fürchten, oder aber keinen
Bedarf bzw.
<br>
Nutzen im HAMNET sehen.. Das ist sehr schade, weil von den
meisten OM's
<br>
das ungeheure Potential nicht erkannt wird, welches im HAMNET
steckt..
<br>
Deshalb ist es umso wichtiger zu zeigen: "Hey!! Guckt mal her..
Wir
<br>
haben HAMNET bereits in Betrieb.. Wollt ihr nicht auch
mitmachen?!"..
<br>
Laß uns beginnen!!
<br>
<br>
<br>
<br>
<br>
Es ist sehr wichtig, schon von Anfang an gewisse Standards in
unserem
<br>
Subnet festzulegen.. Dies dient dazu ein einheitliches Netz zu
schaffen,
<br>
mit dem sich jeder OM verbinden kann, ohne zusätzliche Barrieren
zu
<br>
schaffen.. So sollte jeder, der sich mit HAMNET beschäftigt, die
<br>
hierarchische Struktur bei der IP-Adressvergabe und bei Anfragen
<br>
kennen.. User (OM's), welche Probleme mit ihrem Einstieg oder
der
<br>
Konfiguration haben, melden sich beim regionalen SysOp des
Digipeaters,
<br>
bei dem sich der jeweilige User ins HAMNET einloggen möchte..
Dann wird
<br>
gemeinsam eine Lösung erarbeitet.. Wenn SysOps mit ihrem Wissen
nicht
<br>
mehr weiter kommen, IP-Adressen benötigt werden, Routingfehler
auftreten
<br>
etc., wenden sich die SysOps an den jeweiligen ARIR ([A]MPRNet
<br>
[R]egional [I]P [R]egistry) des jeweiligen Distriktes.. (Im Fall
<br>
Distrikt V bin ich der ARIR)
<br>
Der ARIR verwaltet also die vom ANIR ([A]MPRNet [N]ational [I]P
<br>
[R]egistry) zugeteilten Subnetze.. Der ANIR ist im Fall
Deutschland ein
<br>
Team bestehend aus drei Koordinatoren, welche Deutschland in
drei
<br>
Verwaltungszonen unter sich aufgeteilt
<br>
haben.. So ist Egbert Zimmermann DD9QP für den Bereich Nordwest,
Jann
<br>
Traschewski DG8NGN für den Bereich Süd und Thomas Osterried
DL9SAU für
<br>
den Bereich Ost zuständig.. In diesen Bereichen stehen auch die
<br>
HAMNET-Switches, an denen für die jeweiligen Bereiche auch die
Tunnel
<br>
für HAMNET-Insellösungen enden.. Wenn wir im Distrikt V ein
neues Subnet
<br>
zugeteilt bekommen oder sich die ASN ändert, geht diese Info von
DL9SAU
<br>
direkt zu mir und ich mache diese Info dann im Distrikt
bekannt..
<br>
Umgekehrt wende ich mich bei Fragen und Ideen, welche nicht nur
den
<br>
Distrikt V betreffen, sondern u.U. auch bundesweit Gültigkeit
haben
<br>
(z.B. IPv6) und bei Weiterleitungen von Anfragen von SysOps
unseren
<br>
Distriktes an den ANIR direkt an Thomas DL9SAU..
<br>
<br>
Ein weiterer Punkt der Standardisierung in unserem Distrikt
betrifft die
<br>
Administration der HAMNET-Standorte.. So sollte es
selbstverständlich
<br>
sein, daß sowohl der zuständige SysOp als auch der ARIR Zugriff
auf die
<br>
Geräte der HAMNET-BB-Standorte haben.. Man kann das so wie im
<br>
Freifunknetz "Opennet-Initiative e.V." in Rostock lösen, daß die
AP ein
<br>
einheitliches root-Passwort besitzen, was so bisher problemlos
<br>
funktioniert, weil die Administratoren des Netzes bei Problemen
schnell
<br>
eingreifen können oder zwecks Dokumentation schnell die
Konfiguration
<br>
einsehen können.. Diese Lösung schätze ich schon seit Jahren,
weil das
<br>
lästige hantieren mit Passwortlisten entfällt.. Für unser HAMNET
und
<br>
weil wir Funkamateure alle Rufzeichen haben favorisiere ich
einen
<br>
anderen Ansatz.. Ein root-Account für jedes Device für den
zuständigen
<br>
SysOp und ein User-Account mit Root-Rechten in der Gruppe root
für den
<br>
ARIR (z.B. arir:root).. So kann ich, wenn im späteren Netz
irgendetwas
<br>
nicht stimmt die Konfiguration prüfen und ggf. ändern mit eMail
an den
<br>
jeweiligen SysOp, wo beschrieben wird, welche Änderungen
vorgenommen
<br>
wurden.. Außerdem hat der Login mit einem User-Konto den
Vorteil, daß
<br>
der SysOp einsehen kann, wer und wann sich Jemand eingeloggt hat
und
<br>
welche Eingaben gemacht worden sind.. Ich denke, wir sollten uns
auf den
<br>
letztgenannten Vorschlag einigen..
<br>
<br>
Ein weiterer Standard ist, daß das Routingprotokoll OSPF für das
interne
<br>
Routing im HAMNET-Backbone (Distrikt V) eingesetzt wird.. Ich
habe zwar
<br>
auch über den Einsatz von iBGP nachgedacht, doch ist OSPF gerade
bei
<br>
größeren Netzen skalierbarer.. Bei kleinen Netzen fällt es kaum
ins
<br>
Gewicht, ob man für das Routing iBGP einsetzt, aber sind erst
mal
<br>
(gerade im Endstadium des Ausbaus) viele Knoten zu verwalten,
werden die
<br>
Vorzüge von OSPF erkennbar.. Und wir haben einen Vorteil: Wir
müssen
<br>
dann nicht mehr Umstellen, weil wir bereits OSPF einsetzen.. Nur
die
<br>
Border-Gateways, also die HAMNET-Standorte an unseren
Distriktsgrenzen
<br>
müssen neben OSPF zusätzlich eBGP unterstützen, um
Routinginformationen
<br>
mit den Nachbardistrikten austauschen zu können.. Als
Routingdaemon
<br>
sollten wir uns auf bird oder quagga (vormals zebra) einigen,
wobei bird
<br>
bevorzugt verwendet werden sollte (Empfehlung).. bird ist
einfacher zu
<br>
administrieren.. quagga ist sehr komplex..
<br>
<br>
Außerdem sollte jeder Standort mit der Unterstützung für IPv6
<br>
ausgerüstet sein.. Dies ist keine Vorgabe vom ANIR, aber eine
Empfehlung
<br>
von mir als ARIR.. Da das IPv6-Protokoll eh kommen wird und es
sicher
<br>
auch viele Funkamateure gibt, die mit dem neuen
Internetprotokoll
<br>
experimentieren möchten, sollte es auf JEDEM Device eingerichtet
sein..
<br>
<br>
Weil der Distrikt V keine Anbindung an das HAMNET hat, müssen
wir an die
<br>
oben bereits angesprochene Tunnel-Lösung (VPN) zurückgreifen..
Wir (ANIR
<br>
und ARIR) sehen es nicht gerne, wenn kreuz und quer Tunnel
eingerichtet
<br>
werden, da man so schnell den Überblick verliert und das
Verwalten
<br>
erschwert.. Deshalb lautet die Devise: So wenig Tunnel wie
möglich, so
<br>
viel wie nötig.. Ein Tunnel, im Ausnahmefall zwei Tunnel,
sollten genügen..
<br>
Es würde Sinn machen eine Bridge (HAMNET-Backbone) zwischen
DB0HGW und
<br>
DB0NBB einzurichten und diesen Tunnel bei DB0NBB einzurichten,
weil
<br>
DB0NBB im späteren Endausbau des HAMNET ein zentraler
Knotenpunkt sein
<br>
wird.. Dieser Tunnel hat dann so lange Bestand, so lange noch
keine
<br>
Verbindung zu DB0ZEH besteht.. Ein großes Problem sehe ich im
Aufbau der
<br>
Backbone-Linkstrecke zwischen DB0HGW und DB0NBB aufgrund der
großen zu
<br>
überbrückenden Distanz dieser beiden Digipeaterstandorte (s.
Links
<br>
Distrikt V / Main-Backbone / DB0HGW-DB0NBB).. Hier können nur
Antennen
<br>
mit großem Gewinn oder ein zusätzlicher Hop Abhilfe schaffen..
<br>
Vielleicht sollte man zuvor auch einmal eine Versuchslinkstrecke
<br>
testen.. Über den Link in Richtung DB0HST mache ich mir keine
Sorgen..
<br>
In DB0HST könnte ein BGP-Concentrator stehen, da dort an der
<br>
Fachhochschule eine Verbindung ins DFN besteht..
<br>
<br>
Der Verbindung der einzelnen HAMNET-Standorte sollte über den
Backbone
<br>
im 5cm-Band auf den für den HAMNET-Backbone ausgewiesenen
<br>
Amateurfunkfrequenzen abgewickelt werden.. Die Unterverteilung
zu den
<br>
Usern sollte vorzugsweise im 13cm-Band auf den für
HAMNET-User/Service
<br>
ausgewiesenen Amateurfunkfrequenzen stattfinden (kann aber auch
5cm sein)..
<br>
<br>
Vom ANIR habe ich die AS-Nummer 64642 mit der Domain
DISTRIKT-V-642-AS
<br>
zugewiesen bekommen.. Darin enthalten sind zwei IPv4-Blöcke
<br>
(44.224.44.0/24 für den Backbone und 44.225.88.0/22 für
<br>
User/Service-Netz).. Der IPv6-Prefix fc2c:fc82::/32 wurde nicht
vom ANIR
<br>
zugeteilt, sondern entstammt meines geistigen
Einfallsreichtum.. ;-)
<br>
Wenn die Zeit gekommen ist, dann gerne mehr zu IPv6.. Daraus
habe ich
<br>
die IPv4-Blöcke so aufgeteilt, wie sie seit einigen Jahren auf
<br>
<a class="moz-txt-link-abbreviated" href="http://www.hamnet-dl.de/">www.hamnet-dl.de/</a> veröffentlicht sind.. Gedanken mache ich mir,
ob wir
<br>
die Transfernetze wirklich brauchen.. Aber das wird die Zeit
zeigen..
<br>
Wichtig ist, daß Backbone-Netz und User/Service-Netz stets
getrennt
<br>
bleiben und die Geräte entsprechende IP-Adressen bekommen, wofür
sie
<br>
auch gedacht sind.. So erhält jeder AP im Backbone eine von mir
<br>
zugeteilte IP-Adresse.. Möchtest Du für Deinen Standort zwei
<br>
Linkstrecken betreiben DB0HGW<->DB0HST und
DB0HGW<->DB0NBB wirst Du zwei
<br>
Backbone-IP-Adressen benötigen.. Alle anderen Geräte (Server,
Webcam,
<br>
Repeater (D-STAR), Digipeater (APRS) und sonstige Dienste,
welche mit
<br>
einer festen IP-Adresse erreichbar
<br>
sein müssen) erhalten eine IP-Adresse aus dem
User/Service-Netz-Pool des
<br>
jeweiligen Standortes.. Dies gilt auch für User-Stationen,
welche z.B.
<br>
eine vom HAMNET aus erreichbare Wetterstation oder WebCam von
zuhause
<br>
aus betreiben.. User, welche sich nur mit dem HAMNET Verbinden,
um im
<br>
HAMNET zu surfen, erhalten per DHCP eine IP-Adresse aus dem
DHCP-Pool
<br>
(User/Service) des jeweiligen HAMNET-Standortes..
<br>
<br>
Die vom ANIR für unseren Distrikt zugeteilten IP-Blöcke sind
fest.. Ich
<br>
kann aber nicht sagen, ob sich hinsichtlich der Aufteilung der
<br>
IP-Adressen noch etwas ändern wird, zumal das HAMNET ja noch
wächst..
<br>
Deshalb sind Änderungen jederzeit
<br>
vorbehalten, doch muß der ARIR das ganze managen; dafür ist er
ja da!!
<br>
<br>
Wünschenswert wäre ein Blockbild der HAMNET-Installation, um
sich eine
<br>
genaue Vorstellung von der Konfiguration machen zu können.. Am
<br>
einfachsten geht das mit dem Programm DIA, welches unter Linux
verfügbar
<br>
ist (eine Windows-Version gibt es imo auch).. Diese Skizze
könnte man
<br>
dann ins HAMNET-Wiki hochladen.. So ist es für mich einfacher
die
<br>
Standorte zu koordinieren und Netzlisten zu erstellen und auf
einem
<br>
aktuellen Stand zu halten, um sie an den ANIR weiterreichen zu
können..
<br>
<br>
Die IP-Adressen der jeweiligen Standorte trage ich dann in die
Listen
<br>
ein, sobald der jeweilige Standort aktiv wird.. Diese
IP-Adressen
<br>
bleiben dann auch so zugeteilt, bis sie vom SysOp zurückgegeben
werden..
<br>
Trotzdem sparsam mit den IPv4-Adressen umgehen.. Bei IPv6 ist es
dann
<br>
trivial..
<br>
<br>
Ach so, eine Sache noch, bevor sie mir wieder entfällt.. :-)
DB0HGW
<br>
hängt dann im späteren Main-Backbone.. Dies bedeutet daß dort
der
<br>
Haupt-Traffic fließen wird und deshalb die Hardware entsprechend
<br>
Leistungsfähig (schnelle Plattform und hohe Datenraten) sein muß
und
<br>
stabil laufen sollte.. Dies trifft zwar eigentlich auf alle AP
im
<br>
Backbone zu, aber im besonderen Maße auf den Main-Backbone..
Dieser
<br>
Main-Backbone ist auf der Karte rot eingefärbt.. Der redundante
Backbone
<br>
ist für den Fall wichtig, falls mal ein HAMNET-Standort oder ein
<br>
Backbone-AP ausfällt; vielleicht ja der Backbone-AP bei DB0HGW
für den
<br>
Link DB0HGW<->DB0HST?! ;-) Dann wäre von DB0NBB so kein
durchkommen
<br>
mehr zu DB0HRO, wäre da nicht noch der redundante
Backup-Backbone via
<br>
DO0MAL.. Der BackUp-Backbone ist auf der Karte blau eingefärbt..
Für den
<br>
Einstieg ins HAMNET durch die User kann auch günstige Hardware
verbaut
<br>
werden.. Hier fließen für gewöhnlich nicht so viele Daten wie
auf dem
<br>
Backbone, auf dem die Daten der einzelnen HAMNET-Standort
gebündelt
<br>
übertragen werden..
<br>
<br>
Ich hoffe ich habe mich einigermaßen Verständlich ausgedrückt,
weil ja
<br>
doch einige Fachbegriffe auftauchen.. Trotzdem bemühte ich mich
die
<br>
Anzahl an Fachausdrücken auf ein gesundes Maß zu reduzieren..
Aber
<br>
Fachausdrücke und gängige Abkürzungen vereinfachen die
Verständlichkeit;
<br>
wenn man sie denn versteht.. Deswegen bitte ich um Re, wenn noch
Fragen
<br>
offen geblieben sein sollten..
<br>
<br>
Es freut mich, daß es nun mit HAMNET auch hier endlich losgeht
und sich
<br>
einige OM's zusammengefunden haben einen Anfang zu machen.. Den
<br>
Grundstein dafür hatte ich schon vor Jahren mit der Beantragung
des
<br>
Netzes und einigen Wochen der Netzplanung gemacht.. Ich hoffe,
daß meine
<br>
Vorbereitungen gut durchdacht sind, um so schnell ein
funktionierendes
<br>
und stabiles HAMNET aufbauen zu können.. Diese Ideen, die ich
damals
<br>
hatte, habe ich gleich ins Wiki eingepflegt, welches mein
Scratchboard
<br>
und Dokuablage zugleich war.. Nachdem ich die Netzplanung
abgeschlossen
<br>
habe, mußte das ganze dann durch den Aufbau der HAMNET-Standorte
nur
<br>
noch mit Leben gefüllt werden.. Nun ist es wohl soweit..
Eigentlich ist
<br>
es ja ganz einfach.. SysOps der HAMNET-Standorte schauen auf den
Plan,
<br>
wohin Linkstrecken benötigt werden und versuchen zunächst
testweise eine
<br>
Verbindung zum Nachbarn aufzubauen.. Wenn das klappt kommen die
<br>
Feinheiten (IP-Adresse vergeben lassen und Konfiguration
anpassen).. So
<br>
war eigentlich der Plan von mir, daß SysOps eng mit der Wiki und
dem
<br>
ARIR zusammenzuarbeiten..
<br>
<br>
BTW: Es ist sehr von Vorteil, wenn sich die am HAMNET
interessierten
<br>
OM's in die ML Distrikt V eintragen bzw. diese Liste abonieren..
So
<br>
werden Fragen schnell beantwortet und man bleibt über News auf
den
<br>
Laufenden..
<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.amateurfunk-wiki.de/index.php/Links_Distrikt_V_Mecklenburg-Vorpommern">http://www.amateurfunk-wiki.de/index.php/Links_Distrikt_V_Mecklenburg-Vorpommern</a>
<br>
<a class="moz-txt-link-freetext" href="http://www.amateurfunk-wiki.de/index.php/IP-Koordination_Distrikt_V_Mecklenburg-Vorpommern">http://www.amateurfunk-wiki.de/index.php/IP-Koordination_Distrikt_V_Mecklenburg-Vorpommern</a>
<br>
<a class="moz-txt-link-freetext" href="http://www.amateurfunk-wiki.de/index.php/DB0HGW">http://www.amateurfunk-wiki.de/index.php/DB0HGW</a>
<br>
<a class="moz-txt-link-freetext" href="http://de.ampr.org/mailman/listinfo/hamnet_v/">http://de.ampr.org/mailman/listinfo/hamnet_v/</a>
<br>
<br>
<br>
<br>
73 de Bjørn, DL7RAY& SysOp DB0HRO& ARIR Distrikt V
<br>
<br>
<br>
<br>
<br>
Am 16.08.2012 19:37, schrieb Dirk:
<br>
<blockquote type="cite">Hallo Bjørn,
<br>
<br>
Ich bin der Sysop von DB0HGW und DB0OVP ( Greifswald).
<br>
Du hattest mal vor knapp 2 Jahren eine Rundmail an die Sysop´s
<br>
bezüglich HAMnet im Distrikt V geschrieben. Ich war damals QRL
-
<br>
bedingt sehr beschäftigt.
<br>
Was ist aus dem Projekt geworden? Im Internet habe ich über
die HAMnet
<br>
- Entwicklung im Distrikt V nicht viel gefunden.
<br>
<br>
Wir wollen im Greifswalder Raum jetzt auch am HAMnet bauen.
Als erste
<br>
Anwendungen sind D-Star und APRS in der Planung. Wie ist die
sonstige
<br>
Situation in MV?
<br>
<br>
73 Dirk
<br>
DG0KF
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>