DL-IP-Koordination - hamnet

as-list-de

Anonymous (anonymous@undisclosed.example.com) — 2026-02-28T12:33:31+00:00

# -----------------------------------------
# This is the official list of the German
# AS-numbers and IP-networks used in the
# German HAMNET [-V3.0]
# -----------------------------------------
# created: 2009-08-17
# creator: DL-IP-Coordination Team
# lastmod: 2026-01-01
# review:  2019-11-01
# -----------------------------------------

# ---------
# HAMNET-DL
# ---------
# AS-      AS-                     NETWORKS          NETWORKS           NETWORKS
# NO       NAME                    BACKBONE          USER/SERVICES      PACKET-RADIO

new                                                  44.149.254.0/23    # Anycast

64620      not yet allocated       44.148.0.0/23     44.149.0.0/22
64621      SALZWEDEL-621-AS        44.148.2.0/23     44.149.4.0/22
64622      MANNHEIM-622-AS         44.148.4.0/23     44.149.8.0/22
64623      ROSENHEIM-623-AS        44.148.6.0/23     44.149.12.0/22
64624      LANDSHUT-624-AS         44.148.8.0/23     44.149.16.0/22
64625      MUENCHEN-625-AS         44.148.10.0/23    44.149.20.0/22     44.130.56.0/24
64626      COBURG-626-AS           44.148.12.0/23    44.149.24.0/22                                                                      
64627      KLEVE-627-AS            44.148.14.0/23    44.149.28.0/22     44.130.146.0/24
64628      SACHSEN-628-AS          44.148.16.0/23    44.149.32.0/22
64629      BERLIN-629-AS           44.148.18.0/23    44.149.36.0/22
64630      REGENSBURG-630-AS       44.148.20.0/23    44.149.40.0/22     44.130.59.0/24
64631      ULM-631-AS              44.148.22.0/23    44.149.44.0/22     44.130.53.0/24 44.130.61.0/24
64632      DUESSELDORF-632-AS      44.148.24.0/23    44.149.48.0/22     44.130.19.0/24
64633      DORTMUND-633-AS         44.148.26.0/23    44.149.52.0/22
64634      KOELN-634-AS            44.148.28.0/23    44.149.56.0/22
64635      OSNABRUECK-635-AS       44.148.30.0/23    44.149.60.0/22
64636*     HANNOVER-636-AS         44.224.32.0/23    44.225.64.0/22     44.130.129.0/24
64636      HANNOVER-636-AS         44.148.32.0/23    44.149.64.0/22     44.130.129.0/24
64637      KARLSRUHE-637-AS        44.148.34.0/23    44.149.68.0/22     44.130.29.0/27 44.130.51.0/27
64638      KOBLENZ-638-AS          44.148.36.0/23    44.149.72.0/22
64639      OLDENBURG-639-AS        44.148.38.0/23    44.149.76.0/22
64640      HEILBRONN-640-AS        44.148.40.0/23    44.149.80.0/22
64641      HAMBURG-641-AS          44.148.42.0/23    44.149.84.0/22
64642      GREIFSWALD-642-AS       44.148.44.0/23    44.149.88.0/22
64643      BRAUNSCHWEIG-643-AS     44.148.46.0/23    44.149.92.0/22
64644      STUTTGART-644-AS        44.148.48.0/23    44.149.96.0/22
64645      WUERZBURG-645-AS        44.148.50.0/23    44.149.100.0/22
64646      KREFELD-WESEL-646-AS    44.148.52.0/23    44.149.104.0/22
64647      AUGSBURG-647-AS         44.148.54.0/23    44.149.108.0/22    44.130.58.0/24
64648      BIELEFELD-648-AS        44.148.56.0/23    44.149.112.0/22    44.130.22.0/24
64649      THUERINGEN-649-AS       44.148.58.0/23    44.149.116.0/22
64650      TRIER-650-AS            44.148.60.0/23    44.149.120.0/22    44.130.33.0/24
64651      GOETTINGEN-651-AS       44.148.62.0/23    44.149.124.0/22
64652      AMBERG-652-AS           44.148.64.0/23    44.149.128.0/22
64653      KASSEL-653-AS           44.148.66.0/23    44.149.132.0/22
64654      DUISBURG-ESSEN-654-AS   44.148.68.0/23    44.149.136.0/22    44.130.18.0/24
64655      BREMEN-655-AS           44.148.70.0/23    44.149.140.0/22
64656      SACHSEN-ANHALT-656-AS   44.148.72.0/23    44.149.144.0/22
64657      RAVENSBURG-657-AS       44.148.74.0/23    44.149.148.0/22
64658      BRANDENBURG-SUED-658-AS 44.148.76.0/23    44.149.152.0/22
64659      BRANDENBURG-NORD-659-AS 44.148.78.0/23    44.149.156.0/22
64660      FRANKFURT-660-AS        44.148.80.0/23    44.149.160.0/22
64661      AACHEN-661-AS           44.148.82.0/23    44.149.164.0/22
64662      KIEL-662-AS             44.148.84.0/23    44.149.168.0/22
64663      MUENSTERLAND-663-AS     44.148.86.0/23    44.149.172.0/22
64664      NUERNBERG-664-AS        44.148.88.0/23    44.149.176.0/22    44.130.60.0 44.130.99.0 44.130.254.0
64665      FREIBURG-665-AS         44.148.90.0/23    44.149.180.0/22
64666      WESTFALEN-666-AS        44.148.92.0/23    44.149.184.0/22
64667      DARMSTADT-667-AS        44.148.94.0/23    44.149.188.0/22
64668      KLEVE2-668-AS           44.148.96.0/23    44.149.192.0/22
64669      ROSTOCK-669-AS          44.148.98.0/23    44.149.196.0/22
64670      not yet allocated       44.148.100.0/23   44.149.200.0/22
64671      not yet allocated       44.148.102.0/23   44.149.204.0/22
64672      not yet allocated       44.148.104.0/23   44.149.208.0/22
64673      not yet allocated       44.148.106.0/23   44.149.212.0/22
64674      not yet allocated       44.148.108.0/23   44.149.216.0/22
64675      not yet allocated       44.148.110.0/23   44.149.220.0/22

64676      HAMNET-EVENT1-AS        44.148.112.0/23   44.149.224.0/20 # HAM RADIO Friedrichshafen dauerhaft (DG8NGN)
64677      HAMNET-EVENT2-AS        44.148.114.0/23   44.149.240.0/21 # Sysop Treffen Engen bis 1.4.2026 (DL8SCU)
64678      HAMNET-EVENT3-AS        44.148.116.0/23   44.149.248.0/22 # special events

# ----------
# DL-TEST-AS
# ----------
64679                              DLTEST-AS-16BIT   # local tests in DL
|--4226267900-4226267999           DLTEST-AS-32BIT   # local tests in DL

#          Assignments end here    44.148.117.255    44.149.251.255
#
#          FUTURE USE              44.148.118.0/23 
#          FUTURE USE              44.148.120.0/21

# --------
# HAMCLOUD
# --------
64680      HAMCLOUD-AS                              # HamCloud Spare
64681      HAMCLOUD-AS1           44.148.128.0/20   # HamCloud Datacenter #1
64682      HAMCLOUD-AS2           44.148.144.0/20   # HamCloud Datacenter #2
64683      HAMCLOUD-AS3           44.148.160.0/20   # HamCloud DataCenter #3
#                                 44.148.176.0/20   # temp
#                                 44.148.192.0/18   # HamCloud misc user/services
#
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# !This file is a proposal. Network-aggregation to AS may be subject to change!
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
#
# EOF
#

<-- Zurück

as-nummern

Anonymous (anonymous@undisclosed.example.com) — 2020-12-09T20:29:50+00:00

AS-Nummern im HAMNET

Jedes Autonome System (AS) ist durch eine eindeutige Nummer, die AS-Nummer (ASN), gekennzeichnet. Ein Autonomes System ist ein Netzwerk bzw. eine Gruppe von Netzwerken, die meist eine gemeinsame Administration sowie eine gemeinsame Routing Policy besitzen. Kernstück eines Autonomen Systems sind die dort vorhandenen Router.

16-bit-AS-Nummern

16-bit-AS-Nummern (ASN) ¹⁾ haben nach dem ursprünglichen 16-Bit-Verfahren einen Integer-Wert von 0-65536. Das entspricht 65536 möglichen ASN. Öffentliche ASN, die z.B. im Internet für das BGP benutzt werden, liegen im Bereich von 1 bis 64511. Private ASN, die nur innerhalb einer Organisation in abgeschotteten Netzen (private networks) verwendet werden, müssen im Bereich von 64512 bis 65534 liegen. Das European HAMNET ist ein solch abgeschottetes Netz. Die Aufteilung auf die teilnehmenden europäischen Länder wurde seit 2009 wie folgt koordiniert (Quelle: OEVSV:Digitaler Backbone):

Country	16-bit-AS-Range	Last Update
Austria	64512 - 64599	24.06.2016
Italy	64600 - 64619	01.10.2009
Germany	64620 - 64683	01.10.2009
Luxemburg	64684 - 64685	01.10.2009
Netherlands	64686 - 64704	27.02.2016
Hungary	64705 - 64707	01.10.2009
Spain	64708 - 64719	01.10.2009
Switzerland	64720 - 64739	24.06.2012
Liechtenstein	64740 - 64741	25.06.2012
France	64742 - 64777	13.04.2013
Belgium	64778 - 64788	26.09.2013
Turkey	64789 - 64799	26.09.2013
Poland	64800 - 64839	04.11.2013
Romania	64840 - 64849	09.02.2014
Portugal	64850 - 64854	04.03.2015
Slovenia	64855 - 64864	07.12.2015
Croatia	64865 - 64873	27.02.2016

Die 16-Bit-AS-Nummern dienen im deutschen HAMNET vorrangig der verbesserten Strukturierung in einzelne Regionen und nicht primär dem eigentlichen Routing. Sie müssen nicht in logisch aufeinander folgenden Blöcken beieinander liegen, dafür gibt es keinen technischen Grund.

32-bit-AS-Nummern

32-bit AS-Nummern ²⁾ werden seit Ende 2015 im HAMNET-DL verwendet. Seitdem gibt es eine internationale Übereinkunft zur Verwendung von privaten 32-bit AS-Nummern im 44er AMPRNet. Die Aufteilung auf die einzelnen Länder orientiert sich an dem „International Numbering Plan for Public Data Networks“ (X.121 Document) und der „List of Mobile Country Codes“ (E.212 Document) der ITU. An dieser Stelle wird die Vergabe von lokalen 32-bit-AS-Nummern im European HAMNET gelistet (Auszug):

	Country	32bit-ASN Block	Country Codes X.121	Status
OE	Austria	4223200000-4223399999	232-233	HamnetDB
I	Italy	4222200000-4222499999	222-224	HamnetDB
DL	Germany	4226200000-4226599999	262-265	HamnetDB
LX	Luxemburg	4227000000-4227099999	270	HamnetDB
CR	Croatia	4221900000-4221999999	219	HamnetDB
PA	Netherlands	4220400000-4220599999	204-205	HamnetDB
HA	Hungary	4221600000-4221699999	216	HamnetDB
EA	Spain	4221400000-4221599999	214-215	HamnetDB
HB	Switzerland	4222800000-4222999999	228-229	HamnetDB
HB0	Liechtenstein	4229500000-4229599999	295	HamnetDB
F	France	4220800000-4221199999	208-211	HamnetDB
ON	Belgium	4220600000-4220699999	206	HamnetDB
TA	Turkey	4228600000-4228699999	286	to be generated
SP	Poland	4226000000-4226199999	260-261	HamnetDB
YO	Romania	4222600000-4222699999	226	HamnetDB
CT	Portugal	4226800000-4226999999	268-269	HamnetDB
S5	Slovenia	4229300000-4229399999	293	HamnetDB

Im European HAMNET werden 16-bit ASN und 32-bit-ASN parallel genutzt. Jedes Land kann die Vergaberichtlinien nach eigenen Kriterien festlegen.

weiterführende Informationen:

<-- Zurück

¹⁾

Durch die seit 2015 zur Verfügung stehenden 32-bit AS-Nummern und deren Kompatibilität zu 16-bit-ASN ist das Problem knapper 16-bit Ressourcen obsolet geworden. Jedem Land stehen weltweit 32-bit AS-Nummern in ausreichendem Maß zur Verfügung.

²⁾

Im European HAMNET ist die Verwendung von 16-Bit und 32-bit AS-Nummern voll kompatibel. Sie können auch gemischt eingesetzt werden. Für autonome Systeme (AS), die 16-bit AS-Nummern verwenden, besteht keinerlei Notwendigkeit auf 32-bit AS-Nummern zu wechseln. Sie können ohne irgendwelche technische Nachteile bedenkenlos weiter verwendet werden. Dies ist auch im Internet seit Jahren gängige Praxis.

bgp-mikrotik

Anonymous (anonymous@undisclosed.example.com) — 2026-01-03T11:05:22+00:00

BGP-Routing mit Mikrotik-Routern

Thomas Osterried, DL9SAU
Egbert Zimmermann, DD9QP

RouterOS 6.x oder RouterOS 7.x ?

Im HAMNET werden zumeist Router von Mikrotik eingesetzt. Sehr verbreitet und nach wie vor empfohlen ist die RouterOS Version 6.x. Diese Reihe wird von Mikrotik aktuell weiter gepflegt und mit Updates versehen (Stand Januar 2026). Seit einiger Zeit ist auch die RouterOS-Version 7.x verfügbar. Mit ROS v7.x hat sich die BGP Konfiguration gegenüber ROS v6.x grundlegend geändert, leider ist sie deutlich komplexer geworden. Wer RouterOS-Version 7.x einsetzen muss, weil

die Hardware des neuen Gerätes die alte, stabile Version 6 nicht mehr unterstützt
das in ROS 7.x neu hinzu gekommene VPN Protokoll Wireguard genutzt werden soll
es bgp-sessions effizienter verwalten kann (Multicore Unterstützung) und dadurch laut Mikrotik schneller arbeitet

muss sich zwingend mit der neuen Syntax der Version 7 auseinandersetzen. In allen anderen Fällen (insbesondere bei Link-Devices) bringt im HAMNET ein Wechsel von ROS v6 auf ROS v7 aktuell keinerlei Vorteile oder Mehrwert.

Wer im HAMNET einfach ein automatisches Upgrade von ROS6 auf ROS7 macht, wird ohne vorherige Maßnahmen das Announcement vom Site-Network verlieren. Der Router ist dann nur noch über seine Transfernetz-IP-Adressen oder per RoMon oder direkt vom Linknachbarn aus erreichbar.

Mit diesem Dokument möchten wir zeigen, was mit Blick auf unsere HAMNET Policies zu beachten ist.

RouterOS 6.x

Angenommen wir haben lokal zwei Linkpartner (in den Transfernetzen 44.148.78.x/29):

  44.148.78.0/29 auf dem interface eth1-link-db0aaa

und

  44.148.78.8/29 auf dem interface eth2-link-db0bbb

Das uns zugewiesene Site-Netz beinhaltet alle User/Services Netze und sei

  44.149.36.128/27

Es teilt sich auf in das Service-Netz für die lokalen Server und Devices

  44.149.36.128/28 auf der bridge br-lan

und das User-Netz für die HAMNET-Nutzereinstiege

  44.149.36.144/28 auf der bridge br-users

HAMNET-POLICY: Wir announcen die uns zugewiesenen User/Services-Netze als einen Block (Site-Netz), also als 44.149.36.128/27

(und nicht separat die Subnetze 44.149.36.128/28 und 44.149.36.144/28, und auch nicht alle drei!).

Hintergrund: Jeder Router im HAMNET lernt diese Netze. Bricht irgendwo auf dem Weg ein Link, muss für alle Netze, die über diesen Linkpartner announced wurden, vom Router neu errechnet werden, was jetzt der bessere Weg ist, und dieser wird in die Routing-Table eingetragen. Diese Berechnungen kosten Zeit und die Routen belegen RAM. Die Routingtabellen sollten also so klein wie möglich gehalten werden. Auch beim Routing ist eine kleinere Routingtable schneller durchsucht als eine große .

Wir wollen nicht den mutmaßlichen Performance-Gewinn von ROS v7 wieder verlieren. Auch wollen wir nicht ältere ROS v6 Router (oftmals mit 1-Core-Prozessoren und wenig RAM) an ihre Grenzen bringen. Deshalb achten wir darauf, dass wir die zugewiesenen Blöcke so groß und so zusammenhängend wie möglich announcen.

Wir senden also unsere User/Services Netze als einen großen Block (/27, egal ob wir ihn selbst in kleinere Subnetze unterteilt haben). Lediglich die Transfernetze (in denen unser Router, die Linkeinheiten, remote Router und remote Linkeinheit liegen), aggregieren wir NICHT. Wir legen sie normalerweise in ein /29 Netz.

Diese Vorgehensweise ist nicht neu! Wir haben das schon von Anfang an im HAMNET so gemacht, also auch zu Zeiten von ROS v5 oder ROS v6.

Unsere Konfiguration im alten ROS v6 unterscheidet sich beim User/Services-Netz von den Transfernetzen:

/routing bgp network
add network=44.148.78.0/29 synchronize=yes
add network=44.148.78.8/29 synchronize=yes
add network=44.149.36.128/27 synchronize=no

Site-Netze mit synchronize=no

Das „synchronize=no“ ist bei ROS v6 wichtig, weil ROS nur Netze announced, die in der Routing-Table aktiv eingetragen sind und exakt matchen. Im obigen Beispiel haben wir aber das Netz geteilt und als 44.149.36.128/28 und 44.149.36.144/28 auf zwei getrennte services- und user-Bridge-Interfaces gelegt.

Deshalb haben wir in der BGP-Konfiguration für das /27 Netz synchronize=no angegeben.

Randbemerkung: Best Practice der ISPs im Internet ist, das Netz auf das loopback interface lo zu legen. Das ist immer „up“. Unter ROS v6 gibt es aber kein loopback interface. Man kann sich zwar eines bauen, z. B. als bridge mit

/interface bridge add name=br-lo

und konfiguriert kein teilnehmendes Interface. Man kann aber auch eine sogenannte „blackhole“-Route setzen:

/ip route add dst-address=44.149.36.128/27 type=blackhole

Diese Konfiguration hat den Vorteil, dass man auch für alle Subnetze zuständig ist, auch wenn man beispielsweise das 44.149.36.144/28 noch gar nicht konfiguriert hat, weil der User-Zugang noch nicht aufgebaut worden ist. In Routingentscheidungen gewinnt übrigens immer das „kleinere“ Netz, also das /28 („more specific“). Dass wir das /27-Netz über loopback oder blackhole „geerdet“ haben, hat keinen negativen Einfluss auf unsere darin enthaltenen /28-Subnetze.

Transfernetze mit synchronize=yes

Gehen wir noch kurz auf den Vorteil von synchronize=yes ein. Unsere Transfernetze announcen wir so. Beispielsweise sei unsere Linkeinheit direkt am ethernet-Port eth1-link-db0aaa angeschlossen. Jetzt gehe das Netzteil kaputt. Weil das Interface jetzt nicht mehr „up“ ist, wird automatisch das betreffende /29 Transfernetz nicht mehr per bgp announced.

Vorteil: Unser Linkpartner announced dieses Netz ja auch. Wenn wir wissen möchten, was passiert ist, wollen wir zum Abschätzen der Ursache des Ausfalls auf dessen Funkeinheit nachsehen (log events, oder zu schlechte SNR, …). Announced aber unser defekter Standort weiterhin dieses Netz, und hat dies einen kürzeren Pfad als das Announcement vom Nachbarn db0aaa, dann erreichen wir dessen Funkeinheit nicht. Also ist es praktisch, dass unser Announcement automatisch unterbleibt, wenn das Link-Interface down ist. Bis zur Reparatur könnte man das /29-Announcement in ein /30-Announcement ändern (natürlich ist dann synchronize=no in der BGP Einstellung erforderlich). Das ist der bessere „Match“, und so kommt man während der Reperatur, egal über welchen Weg, wieder an die eigene Funkeinheit. Achtung! Nach der Reparatur nicht vergessen das /30-Announcement wieder zu entfernen!

Tipp: Füllen wir das /29 bei Seite A von unten und Seite B von oben (also bb-A=.1, trx-A=.2, trx-B=.5, bb-B=.6), dann funktioniert oben beschriebener /30-Announcement-Trick. Broadcast Adresse in A ist 3, Netzwerk-Adresse in B ist 4. Läge trx-B auf der .3, dann läge er noch im /30-Announcement von A!

Nach diesen Vorüberlegungen betrachten wir nun ROS v7:

RouterOS 7.x

ROS v7 kennt kein "synchronize=no" mehr!

Wir können also nur announcen, für was wir zuständig sind. Zuständig sind wir, wenn wir eine Route in unserer Routingtable haben. Das können sein:

Interfaces. Ein Interface hat automatisch eine Route wenn es „up“ ist, also das Interface auf enabled steht und der Ethernet-Port belegt ist
Statische Routen (dazu gehört auch eine blackhole Route)
über OSPF- oder anderweitig gelernte Routen

Da wir weiterhin unser /27 als einen Block announcen möchten, dürfen wir bei RouterOS 7.x das Anlegen einer blackhole Route auf keinen Fall vergessen!

Weitere Unterschiede

„/routing bgp peer“ heißt in ROS v7 „/routing/bgp/connection“. Und „/routing bgp instance“ ist in „/routing/bgp/template“ umbenannt. Das „template“ konfiguriert nun die eigene ASN, und andere „defaults“. Die konkreten /routing/bgp/connection Einträge der Peers beziehen sich auf das template (templates=xxx), so dass die Konfiguration ererbt wird, aber noch (wenn nötig) für diese spezielle Verbindung mit anderen Werten überschrieben werden kann.

bgp network in Firewall verschoben

Mit ROS v7 wurde das Menu „/routing bgp network“ in die Firewall-Konfiguration als Adress-Liste verschoben! Auf diese wird dann in der bgp/connection-Konfiguration (ehemals „routing bgp peer“) auf die „/ip/firewall/adress-list“-Einträge verwiesen.

Gut zu wissen: Vergisst man in der bgp connections Konfiguration für einen Peer die Referenz auf die zu announcenden Netze in der address-list anzugeben, lernt der BGP-Partner zwar die Netze die wir selbst über bgp gelernt haben, nicht aber unsere eigenen!

Dies unterscheidet sich grundlegend von der Konfiguration aus ROS v6!

In ROS v6 wirkten sich „/routing bgp networks“ grundsätzlich erst einmal auf alle Peers aus und ließen sich, wenn nötig, über „/routing filter“ ausfiltern.

In ROS v7 wurde „/routing/filter“ deutlich verschlankt. Sie sind nun als input.xxx, output.xxx Filter nach /routing/template/<templatename> bzw. nach /routing/connections/<peername> gewandert.

ROS v6 und ROS v7 Konfiguration

Stellen wir nun die alte Konfiguration der neuen gegenüber:

ROS v6

/routing bgp network
add network=44.148.78.0/29 synchronize=yes
add network=44.148.78.8/29 synchronize=yes
add network=44.149.36.128/27 synchronize=no

/routing bgp instance
set default as=4226267900 router-id=44.149.36.129

/routing bgp peer
add address-families=ip,ipv6 name=DB0AAA nexthop-choice=force-self \
    remote-address=44.148.78.1 remote-as=4226267901 ttl=1
add address-families=ip,ipv6 name=DB0BBB nexthop-choice=force-self \
    remote-address=44.148.78.9 remote-as=4226267902 ttl=1

Optional:
/ip route
add dst-address=44.149.36.128/27 type=blackhole

Eine solche, in ROS v6 optionale, blackhole-Route für das gesamte Site-Netz sollte man vor einem automatischen Upgrade von ROS v6 auf ROS v7 unbedingt eintragen. Dadurch verringert sich die Chance, dass man nach erfolgtem Upgrade und Neustart die Remote-Erreichbarkeit des Devices verliert.

ROS v7

/ip/firewall/address-list
add address=44.148.78.0/29 comment=DB0AAA list=bgp-advertise
add address=44.148.78.8/29 comment=DB0BBB list=bgp-advertise
add address=44.149.36.128/27 comment=userservices list=bgp-advertise

/routing/bgp/template
set default as=4226267900 router-id=44.149.36.129 \
    output.network=bgp-advertise nexthop-choice=force-self

/routing/bgp/connection
add address-families=ip,ipv6 as=4226267900 name=DB0AAA \
    nexthop-choice=force-self output.network=bgp-advertise \
    remote.address=44.148.78.1 .as=4226267901 .ttl=1 templates=default
add address-families=ip,ipv6 as=4226267900 name=DB0BBB \
    nexthop-choice=force-self output.network=bgp-advertise \
    remote.address=44.148.78.9 .as=4226267902 .ttl=1 templates=default 

/ip/route
add dst-address=44.149.36.128/27 blackhole

Die Blackhole-Route wird bei ROS v7 zwingend nötig damit das eigene /27 Site-Netz announced wird.

Hinweis: Beachte dass „type=“ nicht mehr vor „blackhole“ steht.

Die Address-List führt den Listennamen „bgp-advertise“ ein, auf den in bgp/template und bgp/connection Bezug genommen werden kann (output.network=).

Zu /routing/bgp/connection:
as, output.network, nexthop-choice sollten eigentlich vom template geerbt werden.. ..aber sicher ist sicher.

Zur seltsam anmutenden Syntax „.as“, .ttl„ und andere mit .irgendwas:
Diese bezieht sich auf eine vorherige Zuweisung. remote.address=44.148.78.1 .as=4226267901 ist also gleichwertig zu remote.address=44.148.78.1 remote-address.as=4226267901

Wer das allerdings sortieren will zu as=4226267900 .as=422626790 name=DB0AAA fällt auf die Nase weil .as nun als as.as interpretiert würde. Das gibt es genauso wenig wie beispielsweise input.network.

URL dieser Seite: https://de.ampr.org/hamnet/bgp-mikrotik

bgp-policy

Anonymous (anonymous@undisclosed.example.com) — 2020-12-09T20:34:05+00:00

BGP Routing Policy

Erfahrungen beim Betrieb der vergangenen Jahre zeigen, dass ein Parent-AS über nicht mehr als 16 Standorte (Sites) verfügen sollte. Andernfalls gehen die Übersichtlichkeit verloren oder IP-Netze werden knapp. Ein so großes AS ist dann kaum noch administrierbar. Werden es also mehr Standorte, wird man um die Einrichtung eines weiteren AS in der Region nicht herum kommen.

POLICY: Im European HAMNET erfolgt der Austausch der Routinginformationen zwischen einzelnen AS grundsätzlich per eBGP-Routing.
POLICY: Innerhalb eines AS können auch andere Routingprotokolle verwendet werden. Hat ein AS mehrere AS-Nachbarn, so ist sicherzustellen, dass die Border-Router (eBGP) allen Nachbarn gleiche Routinginformationen übermitteln.
POLICY: Schleifenbildungen und flappende Routen sind durch geeignete, technische Maßnahmen zu verhindern.
POLICY: Im deutschen HAMNET sollte unbedingt „Site-to-Site eBGP“ betrieben werden.

BGP-Confederations

Am Ende des im HAMNET-DL genutzten 16-bit-ASN Bereichs wurde für BGP-Confederations der private 16-bit-ASN-Block 65510-65534 reserviert. Dieser lokale Testbereich kann innerhalb eines (kleineren) AS eingesetzt werden, um z.B. zu testen oder Routen per iBGP innerhalb einer Confederation zu vermitteln. Nach außen hin müssen sie an den eBGP Boarder-Routern des AS aggregiert und unter der original zugewiesenen AS-Nummer announced werden. Confederation-ASN müssen an den Netzgrenzen des AS gefiltert werden (Im- und Export). Diese AS-Nummern dürfen niemals in BGP-Pfaden außerhalb des AS auftauchen. Dadurch sind sie innerhalb des ganzen European HAMNET in jedem AS erneut verwendbar.

POLICY: Confederation-AS-Nummern dürfen niemals im AS-Pfad außerhalb des eigenen AS auftauchen.
POLICY: eBGP Router sind angehalten, Local-Test-AS zu filtern (in und out), damit die Auswirkungen lokal bleiben.

Die DL-IP-Koordination empfiehlt dringend, aufgrund von fehlerhafter Behandlung in Routern und unvorhersehbarer Seiteneffekte keine BGP-Confederations im HAMNET-DL zu verwenden.

Anmerkung: In DL haben wir im oberen Bereich 5 Test-ASN von 64679-64683 reserviert (s. DLTESTx-AS). Diese AS-Nummern werden nicht gefiltert. Sie dienen dazu, schnell und unbürokratisch sein neues AS „online“ zu bringen und die Zeit bis zur Vergabe einer ordentlichen AS Nummer durch die DL-IP-Koordination überbrücken zu können. Es muß darauf geachtet werden, dass die ASN, die ja eindeutig sein muß, nicht schon andernorts im Netz vergeben und aktiv ist. Deshalb bitten wir dringend um Mitteilung vor Verwendung.

<-- Zurück

contact

Anonymous (anonymous@undisclosed.example.com) — 2020-11-28T15:44:08+00:00

Ansprechpartner

Zuständigkeit nach Regionen

Regionalspezifische Fragen können zeitnah am besten durch ein Teammitglied beantwortet werden, das der anfragenden Region am nächsten benachbart ist. Dies erspart unnötige Weiterleitungen von Anfragen innerhalb der DL-IP-Koordination. Besonders wichtig kann dies bei topografischen Problemen im Zusammenhang mit der Linkplanung und der Anbindung einer Region an ein Nachbar-AS werden. Anfragen nach Unterstützung vor Ort oder nach Vorträgen und/oder Workshops durch ein Mitglied der DL-IP-Koordination anlässlich von Tagungen, lokalen Sysoptreffen oder sonstigen Veranstaltungen können so ebenfalls wesentlich besser organisiert werden.

Um solche und ähnliche Besonderheiten einzelner Regionen besser berücksichtigen zu können, wurde das Zuständigkeitsgebiet auf die einzelnen Teammitglieder der DL-IP-Koordination aufgeteilt. Als Anhaltswerte dienten dabei die Distrikte innerhalb des DARC. Welche Gebiete von welchem Teammitglied betreut werden, kann man der nebenstehenden Karte entnehmen. Kontaktieren Sie das zuständige Teammitglied, wenn Sie unnötige Wartezeiten vermeiden wollen:

Bereich Nordwest	Egbert Zimmermann	DD9QP
Bereich Süd	Jann Traschewski	DG8NGN
Bereich Ost	Thomas Osterried	DL9SAU

Zuständigkeit nach Sachgebieten

Bei Fragen rund um IP-Netze, AS-Nummern oder DNS hilft die DL-IP-Koordination AmprNet gerne weiter. Wir haben uns die Arbeit auch nach Sachgebieten aufgeteilt, damit Anfragen schneller bearbeitet und beantwortet werden können.

DD9QP	DL9SAU	DG8NGN
AS-Betreuung Nord/West	AS-Betreuung Nord/Ost	AS-Betreuung Süd
Anbindung DL → PA/F/LX	Anbindung DL → Nord-/Osteuropa	Anbindung DL → Süd-Europa
BGP-Routing	BGP-Routing	BGP-Routing
Hub-West (DNS + Router)	Hub-Ost (DNS)	Hub-Süd (DNS + Router)
IPv4	IPv4 + IPv6	IPv4 + IPv6
internationale Kontakte	internationale Kontakte	internationale Kontakte
Registrierung ASN + IP-Netzvergabe	DNS/BECIX	Gateways/externe Netze
Dokumentationen	Transfer DNS → ampr.org	AX.25/IGATE
Website/Wiki	Scripting/Software	Hardware
WHOIS-Server	HamCloud	HamCloud
Anfrage	Anfrage	Anfrage

dns-system

Anonymous (anonymous@undisclosed.example.com) — 2020-12-09T20:26:46+00:00

Das DNS-System im HAMNET

DNS-Hubs

Kernstück des DNS-Systems im HAMNET-DL bilden drei sogenannte DNS-Hubs. Sie sind an drei verschiedenen, technisch und physikalisch gut erreichbaren Standorten in DL verteilt untergebracht. Sie sind untereinander redundant, teils über schnelle Internet-Tunnel, direkt verbunden und halten das an den Parent-AS abgeleitete Subzonenkonzept im HAMNET-DL zusammen. Eine von der IP-Koordination DL betriebene Transfer-Instanz sorgt als Net-44 Interface für die korrekte Übersetzung der Subzonennamen in die weltweite „flat“-domain ampr.org. Die DNS-Hubs beantworten für ihre Clients neben allen Zonen und der flachen ampr.org Zone auch andere Anfragen (z. B. aus dem Internet). Deshalb genügt in den einzelnen Regionen der Parent-AS das Aufsetzen einfacher „Cache-only“-Nameserver, die dann vor Ort alle angeschlossenen Clients der Region bedienen. Die an jedem Standort vorhandenen Mikrotik-Router können für die Standort-Clients eine solche Aufgabe problemlos übernehmen.

Internet
MASTER-DNS
CNAME
ns.ampr.org

<name>.ampr.org
transfer into
Net-44 Interface
<name>.as64xxxyy.de.ampr.org

<name>.as64xxxyy.de.ampr.org
DNS-Hub WEST
CNAME
dl-west.ampr.org

<name>.as64xxxyy.de.ampr.org
DNS-Hub SUED
CNAME
dl-sued.ampr.org

<name>.as64xxxyy.de.ampr.org
DNS-Hub OST
CNAME
dl-ost.ampr.org

Workflow

Bottom/Up

Die Zonen-Maintainer einzelner Parent-AS haben wahlweise 2 Möglichkeiten, ihre DNS-Einträge weltweit zur Verfügung zu stellen. Methode 1 ist in der Regel voreingestellt. Methode 2 erfordert vor Ort erweiterte DNS-Kenntnisse und eine einmalige Absprache mit der IP-Koordination DL.

Methode	Verfahren
1. HamnetDB	Systeme aller AS-Standorte in die HamnetDB einpflegen
2. Auth-DNS	Eigenen Auth-DNS betreiben mit Anbindung an einen DNS-Hub

Weiterführende Informationen

In beiden Fällen erfolgt die automatische Übertragung von DNS-Daten aus dem HAMNET Bottom/Up bis hinauf zur höchsten Instanz, dem DNS-Master für AMPR.ORG. AS-Maintainer brauchen sich nicht weiter um den Austausch und die weitere Verbreitung ihrer Zonendateien in DL zu kümmern.

Der Zonentransfer geschieht fast zeitgleich automatisch per Notify nach einer Änderung/Aktualisierung durch den AS-Maintainer oder nach Ablauf der Gültigkeitsdauer der verfügbaren Zonen-Dateien im Auth-DNS-Server (TTL gesteuert). Hört der zuständige DNS-Hub von einem lokalen Auth-DNS allerdings längere Zeit nichts, fragt er seinerseits dort nach, ob Änderungen in den Zonen-Dateien für das Parent-AS gibt.

Datentransfer findet nur dann statt, wenn sich in einer Zonendatei wirklich etwas geändert hat. Durch die feste Zuordnung der lokalen Auth-DNS-Server eines Parent-AS auf den zugewiesenen DNS-Hub bleibt der Datenfluss auf die im allgemeinen sicher genug funktionierenden Richtfunkstrukturen der Region beschränkt. Mehrfachbelastungen überregionaler Funkstrecken fallen komplett weg.

TopDown

Das Verteilen der Zonendateien von Zonen außerhalb des eigenen Parent-AS geschieht analog zum beschriebenen BottomUp ebenfalls scriptgesteuert nach dem Top-Down Verfahren. Dies geschieht durch eine spezielle Konfiguration des lokalen Auth-DNS-Servers am lokalen Standort automatisch.

Die lokalen DNS-Server holen sich völlig automatisch alle ihnen fehlenden Zonendateien von dem für sie zuständigen DNS-Hub und müssen nicht mehr kreuz und quer durch die Republik „einsammeln“. Der dafür erforderliche Traffic beschränkt sich ebenfalls auf die Interlinkstrukturen der eigenen Region. Durch den Wegfall von Mehrfachübertragungen von immer den gleichen Daten werden auch hierbei „überregionale“ Richtfunkstrecken entlastet.

Weil alle drei DNS-Hubs über direkte Internetanbindung verfügen, ist es für jeden an einen solchen Hub angebundenen lokalen DNS-Server möglich, per Caching-Abfrage auch alle anderen, internationalen Domainnamen und damit auch das gesamte Internet auflösen zu können. Man bedenke, dass das Auflösen beliebiger Domainnamen und IP-Adressen für die meisten Standorte, die keine eigene Internetverbindung haben, sonst nicht möglich wäre.

<-- Zurück

dnsnames-hamnet

Anonymous (anonymous@undisclosed.example.com) — 2020-12-09T20:27:26+00:00

Host- und Domainnamen in einem AS

Jedes Parent-AS verwaltet für alle Sites eigenverantwortlich die IP-Adress- und Namenszuweisungen. Dies erfordert eine Aufteilung des Namensraumes im deutschen HAMNET in jeweils mindestens 6-7 DNS-Zonendateien pro Parent-AS. Die Zonen dienen im DNS-System sowohl der Vorwärts- als auch der Rückwärts-Auflösung aller dem Parent-AS zugewiesenen Netze. Diese Zonen sind zuvor von der IP-Koordination DL an die Parent-AS delegiert worden. Die Syntax der Namensvergabe innerhalb der Zonendateien lehnt sich an das Regionalzonenkonzept der Nameserver im guten, alten Packet-Radio-Netz an.

Das folgende Beispiel zeigt einen FQDN (Full Qualified Domain Name), also die vollständige Bezeichnung für einen Router des Links von DB0RES zu DB0EEO am Standort von DB0RES im autonomen System mit der AS-Nummer 64627 (DISTRIKT-L-627-AS):

       trx-eeo.db0res.as64627.de.ampr.org
       |       |      |       |  +-------  DOMAINNAME für das internationale AMPRNET (44.0.0.0/9 + 44.0.0.0/10)
       |       |      |       +----------  COUNTRY im AMPRNET (ermöglicht echte Delegation im Internet!)
       |       |      +------------------  ZONENAME eines AS (Unterscheidung der verschiedenen AS-Zonen)
       |       +-------------------------  CALLSIGN vom jeweiligen STANDORT innerhalb des AS
       +---------------------------------  HOSTNAME für ein Gerät, einen Dienst, Router, eine IP-Steckdose etc.

FQDN im HAMNET

DOMAINNAME

Das AMPRNET hat weltweit den Domainnamen „ampr.org“. Diese Domain wird auch im Internet gehostet. Namensauflösungen für Amateurfunk-Hosts aus der ganzen Welt sind damit auch dann noch möglich, wenn sich die beiden Hosts wegen fehlenden Routings gegenseitig nicht erreichen können. Das DNS-System funktioniert sowohl FORWARD als auch REVERSE, z.B. bei traceroutes. Die IP-Koordination DL übersetzt alle FQDN-Namensbezeichnungen aus dem HAMNET automatisch in die flache „Kurzform“ der „ampr.org“-Domain, wenn die Namesngebung bestimmte Bedingungen erfüllt. Dadurch sind alle HAMNET-Hosts überall in der Welt auch für alle anderen Netzteilnehmer auflösbar, die ansonsten keinen Zugriff auf die HAMNET-eigenen DNS-Server haben. Durch die Gateways des AMPRNET wird das HAMNET für alle Funkamateure weltweit erreichbar gemacht.

COUNTRY

Der Landeskenner kennzeichnet die Herkunft dieses Eintrages. Dies ist vor allem eine Investition in die Zukunft. Hierdurch wird es nämlich zu einem späteren Zeitpunkt möglich, diese Zone im Internet komplett an Deutschland auf eigene DNS-Server zu delegieren. Dies würde auch im Internet eine absolut eigenständige Verwaltung aller Zoneneinträge für alle deutschen „ampr-org“-Hosts ermöglichen. Es ermöglicht darüber hinaus auch eine wesentlich effektivere Nutzung besonderer Einträge (Records) in das DNS-System (MX, CNAME, TXT, Geodaten usw).

ZONENNAME

Der Zonenname ersetzt die bekannten Regionsnamen des alten Regionalzonenkonzeptes. Im HAMNET steht hier die AS-Nummer des autonomen Systems, zu dem diese Zonendaten gehören. Da laut RFC die einfache Nennung von Ziffernfolgen an dieser Stelle verboten ist, wurde die AS-Nummer mit der Buchstabenfolge „as“ ergänzt. Die Domain für ein AS im HAMNET ist ab hier eindeutig beschrieben. Alles, was jetzt noch an Bezeichnern vorangestellt wird, gehört zu diesem AS.

CALLSIGN

Ein AS besteht in der Regel aus mehreren, innerhalb des AS vernetzten Standorten (Digis, D-Starrelais, ATV-Relais, Echolink, Clubstation, User usw), denen ein Rufzeichen eindeutig zugewiesen wurde. Ein Standort bildet deshalb die nächst kleinere Einheit im Namenssystem. Gäbe es nur ein Gerät an diesem Standort, wäre dieser Bezeichner gleichzeitig auch der Hostname. In vernetzten Systemen ist das aber in der Regel nicht so.

HOSTNAME

Der Hostname kennzeichnet den lokalen Namen des entsprechenden Gerätes (z.B. Router), eines Dienstes (z.B. WWW) oder sonstiger Devices (z.B. IP-Steckdosen). Sind an einem Standort viele solcher Hardware-Einheiten vorhanden, empfiehlt es sich, das Rufzeichen als Subdomain zu benutzen, und den eigentlichen Gerätenamen durch Punkt getrennt voranzustellen.

Das Net-44 Interface

Eine bei der IP-Koordination DL betriebene Instanz stellt als Net-44 Interface das Bindeglied zwischen der weltweiten, flachen ampr.org-Domain und dem subdomain-basierten Zonenkonzept im HAMNET bereit. Hier werden die FQDN-Hostnamen des deutschen HAMNET in die flachen ampr.org Namensbezeichnungen umgewandelt. Einträge, die der Policy der flachen ampr.org-Struktur entsprechen, werden ins weltweite DNS-System hochgeladen. Unzulässige Einträge werden blockiert und mit Bitte um Prüfung an die zuständigen AS-Maintainer zurück geschickt.

Zulässige Beispiele für FQDN im HAMNET

Ein WWW- oder News-Server bei DB0RES könnte dann beispielsweise so heißen:

www.db0res.as64627.de.ampr.org  -- wird im Internet zu -> www.db0res.ampr.org
news.db0res.as64627.de.ampr.org -- wird im Internet zu -> news.db0res.ampr.org

Zulässig sind auch durch Bindestrich mit dem Standortnamen verbundene Bezeichner.³⁾) Dies lässt sich einsetzen, wenn an einem Standort die Menge der verschiedenen Dienste oder Devices relativ überschaubar ist. Auch Mischformen zwischen beiden Varianten können vorkommen. Zulässige Beispiele könnten sein:

db0shg-router1.as64636.de.ampr.org -- wird im Internet zu -> db0shg-router1.ampr.org
webcam-db0sha.as64636.de.ampr.org  -- wird im Internet zu -> webcam-db0sha.ampr.org
db0res-svr.as64627.de.ampr.org     -- wird im Internet zu -> db0res-svr.ampr.org

POLICY: Ein FQDN-Name ist im HAMNET immer so zu wählen, dass nach automatischer Übertragung in die flache „ampr.org“-Domain immer noch ein Rufzeichen erkennbar bleibt.

Unzulässige Beispiele für FQDN im HAMNET

Bedingt durch die automatische Umsetzung aller DNS-Einträge in die flache „ampr.org“-Domain gibt es leider auch Einschränkungen bei der Namenswahl. Namen, die nach erfolgter Umsetzung kein Amateurfunkrufzeichen mehr enthalten, sind für Funkamateure in anderen Teilen der Welt nicht mehr zuzuordnen. Außerdem beteht bei bestimmten Kombination die Gefahr, dass ein bereits existierender Eintrag überschrieben bzw. ein Fake/Doppel entsteht. Das stört den Betrieb des bereits existierenden Eintrages empfindlich. Derartige Einträge werden deshalb nicht automatisch übernommen und verbreitet. Einige unzulässige und deshalb verbotene Beispiele sind:

router.as12345.de.ampr.org  <- würde transformiert zu -> router.ampr.org (VERBOTEN!)
im4ham.as12345.de.ampr.org  <- würde transformiert zu -> im4ham.ampr.org (VERBOTEN!)
www.as12345.de.ampr.org     <- würde transformiert zu -> www.ampr.org (VERBOTEN!/GIBT ES SCHON!)
www.54321.de.ampr.org       <- würde transformiert zu -> www.ampr.org (VERBOTEN!/GIBT ES SCHON!)
hamgate.as12345.de.ampr.org <- würde transformiert zu -> hamgate.ampr.org (VERBOTEN! NICHT EINDEUTIG!)

POLICY: Alle Einträge in einen Nameserver des HAMNET müssen auch nach Umwandlung in die flache „ampr.org“-Domain noch eindeutig sein und dürfen keine Doppeleinträge erzeugen. Dies kann derzeit durch Verwendung der weltweit eindeutig vergebenen Rufzeichen im FQDN sichergestellt werden.

Registrierung persönlicher Rufzeichen im DNS

Eine Sonderrolle stellt der Eintrag persönlicher Rufzeichen in das DNS-System dar. Hier greifen besondere Vorschriften hinsichtlich des Schutzes bei der Speicherung, Verarbeitung und dem Transfer persönlicher Daten in Nicht-EU-Länder (DSGVO). Eine automatische Übertragung persönlicher Rufzeichen in die flache ampr-org-Domain findet deshalb nicht statt. Sie ist jedoch in begründeten Einzelfällen möglich, wenn der Besitzer des persönlichen Rufzeichens gegenüber der IP-Koordination DL bzw. ihren beauftragten AS-Maintainern sein Einverständnis erklärt und dabei versichert, dass er die von der IP-Koordination DL erstellten Datenschutzhinweise zur Kenntnis genommen und verstanden hat:

Datenschutzerklärung zum Eintrag persönlicher Rufzeichen in das DNS-System

<-- Zurück

³⁾

Die Eintragung von Hostnamen mit Bindestrichen ist in der HamnetDB eingeschränkt!

dnssetup-hamnet

Anonymous (anonymous@undisclosed.example.com) — 2020-12-09T20:36:32+00:00

Einrichtung und Betrieb von Auth-DNS-Servern

Die Einrichtung und der Betrieb eines Auth-DNS-Servers für ein Parent-AS erfordert erhöhte Kenntnisse über Netzwerktechnik, das eingesetzte Betriebssystem und Erfahrungen zur Einrichtung von Serverdiensten. Die IP-Koordination DL empfiehlt die Einrichtung von Auth-DNS nur, wenn in dem Parent-AS ausreichend Kenntnisse darüber vorhanden sind und auch nachhaltig auf geeignete Sysadmins zurück gegriffen werden kann.

Allgemeine Anforderungen

Vorausgesetzt seien:

ein 64bit-fähiger Rechner oder eine VM auf einem lokalen Hostsystem
Betriebssystem Linux (z.B. Debian, Raspbian, Ubuntu)
konfigurierter, funktionsfähiger IP-Stack
root Rechte auf dem Rechner oder der VM
ein installierter BIND9 als DNS-Server

Grundkonfiguration

Die Bind-Konfigurations-Datei steht bei Debian und Debian-ähnlichen Betriebssystemen unter „/etc/bind/named.conf“. In ihr befinden weitere Verweise auf Konfigurationsdateien mit Konfigurations-Parametern wie

standalone, forwarders, Access-Listen, etc..
Timing-Parameter
Logging
Zonen (master, slave, Filename, Pfade dorthin)
etc..

Wenn in einem Parent-AS die eigene Zone verwaltet werden soll, sind die Daten in entsprechenden Zonen-Dateien für Vorwärts- und Rückwärts-Auflösungen abzulegen und zu pflegen. Für diese Zonen ist der DNS dann MASTER-DNS. Diese Zonendaten werden automatisch an den zuständigen DNS-Hub gemeldet, der sie sofort an alle anderen Systeme im HAMNET ausliefern kann. Gleichzeitig benötigt der Auth-DNS einer Zone aber auch Kenntnis über alle anderen verfügbaren Zonen im HAMNET. Die holt er sich auch vom zuständigen DNS-Hub. Für diese Zonen ist der Auth-DNS dann SLAVE-DNS. Fremde Zonen können sich jederzeit ändern, entfallen oder neue hinzugefügt werden.

Die IP-Koordination DL hat ein automatisiertes, script-gesteuertes Verfahren entwickelt, mit dem lokale Auth-DNS automatisch auf Veränderungen im DNS-Netz angepasst werden. Die hierzu erforderlichen Scripte und Steuerdateien werden von der IP-Koordination DL gepflegt und auf verschiedenen Wegen zur Verfügung gestellt.

DNS-Server auf einem Auth-DNS konfigurieren

<-- Zurück

exampleserviceandusernet

Anonymous (anonymous@undisclosed.example.com) — 2015-08-15T14:08:31+00:00

Das Netz für Nutzer und Dienste (User und Services) hat üblicherweise die Größe von einem /24. Es kann für die Nutzung von Segmenten an unterschiedlichen Standorten weiter unterteilt werden.

An einem Standort sollten etwa 30 Nutzer (User) versorgt werden können. → Größe /27 für DHCP.

Mehrere Zugänge am Standort? Gebridged oder geroutet? → Ggf. zwei /27 oder ein /26 nötig.
Standorte gebridged? → größeren DHCP Bereich und weniger Segmentierung des /24.

Der DHCP Bereich kann in einem eigenen Netzsegment mit Bitmask-Grenzen liegen, muss aber nicht.

Vorteil: Jederzeit den veränderten Bedürfnissen anpassbar
Nachteil: User und Dienste in einer Broadcast-Domain.

Im AS gibt es mindestens einen DNS Server. An weiteren Standorten sind ggf. DNS Cache erforderlich.

Innerhalb des AS gibt es Dienste wie Webserver, Mailserver, Proxy. Gatweway ins klassische PR Netz (Telnet-Zugang, AXIP o.ae.).

Segmentierungs-Beispiele

A

5 geroutete Standorte innerhalb eines AS. Standort E mit extrem kleinem Einzugsbereich. Standort D hat am Standort APRS, WX-Station, DNS-Cache und 2 IPs in Reserve.

44.128.128.000/27 - Standort A - Services (32 Adressen)
44.128.128.032/27 - Standort A - DHCP (32 Adressen)
44.128.128.064/26 - Standort B - DHCP (64 Adressen)
44.128.128.128/26 - Standort C - DHCP Range 130-185. 186-190 für lokale Rechner am Standortgenutzt. 
44.128.128.192/27 - Standort D - DHCP (32 Adressen)
44.128.128.225/28 - Standort E - Services (16 Adressen)
44.128.128.240/28 - Standort E - DHCP (16 Adressen)

TODO: more to come

faq

Anonymous (anonymous@undisclosed.example.com) — 2020-03-05T04:46:48+00:00

HAMNET FAQ

Migration auf neue IP-Netze

Die anstehende Migration des deutschen HAMNET auf neue IP-Netze wirft Fragen auf. Einige sollen an dieser Stelle beantwortet werden. Diese FAQ ist eine Momentaufnahme des gegenwärtigen Diskussionsstandes. Alle ausgesprochenen Empfehlungen können sich auf Grund weiterer Entwicklungen und Erfahrungen noch verändern.

Terminplanung

Q: Bis wann muss eine Umstellung erfolgen?

A: Die Umstellung sollte ab jetzt innerhalb eines Jahres erfolgen. Die Deadline wäre demnach der 01.11.2020. Aktuell haben die meisten AS einfach den doppelten IP-Adressbereich bekommen, so dass eine sanfte Migration jederzeit möglich ist. An den Standorten entscheidet ihr selbst, ob ihr einzelne Geräte gleichzeitig oder nacheinander umstellt. Nur bei den Linkstrecken ist die Abstimmung mit dem Linkpartner nötig. Lasst euch daher bitte Zeit und wartet evtl. bis weitere Erkenntnisse und Anleitungen vorliegen.

Grundprinzipien

Q: Welche Grundprinzipien sollten bei der Umstellung beachtet werden?

A: Du solltest dir bei deiner Planung über den grundsätzlichen Aufbau des HAMNET-Backbones im Klaren sein:

Der HAMNET-Backbone besteht aus folgenden Standorten:
- Automatisch arbeitende Amateurfunkstellen mit Genehmigung der BNetzA
- ISM-Standorte soweit sie Relevanz für den HAMNET-Backbone haben (z. B. Verbindung von Teilen des HAMNET-Backbones über ISM-Standorte)
  - ISM-Standorte tragen das Rufzeichen des Verantwortlichen ein
    - mit laufender SSID wenn abweichend vom eigenen Standort.
    - ohne SSID wenn Standort mit dem Standort des persönlichen Rufzeichens übereinstimmt.
Die Karte der HamnetDB soll in der Standardansicht nur den HAMNET-Backbone darstellen.
- Nur für den HAMNET-Backbone relevante Standorte werden mit dem Typ „Hamnet-Site“ in der Datenbank eingetragen.
- Für den HAMNET-Backbone unrelevante ISM-Linkstrecken können durch entsprechend große Wahl des IP-Bereichs des nächstgelegenen HAMNET-Standorts intern realisiert werden damit die Aussenansicht über die Karte unangetastet bleibt. ⁴⁾
Der HAMNET-Backbone soll für alle HAMNET-User komplett sichtbar sein, ein „Traceroute“ durch das HAMNET soll jeden einzelnen HF-Hop anzeigen. Dazu ist es erforderlich, dass jede Linkstrecke ein eigenes Transfernetz erhält (keine Bridges im HAMNET-Backbone!).
Jedes AS erhält ein /22-Netz für Site-Networks (AS-User/Services) und ein /23-Netz (AS-Backbone) für Backbone-Networks.
Jedes AS erhält eine 16-bit AS-Nummer (Root- bzw. Parent-AS) aus der 100 32-bit AS-Nummern für die einzelnen HAMNET-Standorte im AS hervorgehen.
Jeder HAMNET-Standort hat genau einen BGP-Router und nutzt eine 32-bit AS-Nummer.
- Die genutzten 32-bit AS-Nummern werden in der HamnetDB an die dazugehörige 16-bit AS-Nummer gehängt.
Jeder HAMNET-Standort erhält ein Site-Network (mindestens /27) welches intern in passende Service- und Usernetze aufgeteilt wird (z.B. /28 Servicenetz + /28 Usernetz).
Das Site-Network jedes HAMNET-Standorts muss so groß gewählt werden, dass es an einem Stück im HAMNET announced werden kann (nur ein Site-Network-Announcement pro Standort!).
- Jedes Site-Network wird an der passenden 32-bit AS-Nummer in der HamnetDB aufgehängt.
Jedes HF-basierte Transfernetz im HAMNET erhält ein /29-Subnetz
- Die erste IP trägt der Router von Standort A und wird mit dem Typ „Routing-Radio“ oder „Routing-ISM“ in der HamnetDB eingetragen.
- Die zweite IP trägt die Linkeinheit von Standort A (sofern nicht bereits im Router) und wird mit dem Typ „Service“ in der HamnetDB eingetragen.
- Die vorletzte IP trägt die Linkeinheit von Standort B (sofern nicht bereits im Router) und wird mit dem Typ „Service“ in der HamnetDB eingetragen.
- Die letzte IP trägt der Router von Standort B und wird mit dem Typ „Routing-Radio“ oder „Routing-ISM“ in der HamnetDB eingetragen.
Jedes Transfer-Network wird an der passenden 16-bit-AS-Nummer (Parent-AS) in der HamnetDB aufgehängt.

Ressourcenplanung

Q: Wie gehe ich am besten bei der Ressourcenplanung vor?

A: Als AS-Administrator solltest du bei der Aufteilung der zur Verfügung stehenden Ressourcen einige Prinzipien beachten, die sich in den letzten Jahren bewährt haben.

Für jeden Standort wird eine 32-bit AS-Nummer gewählt und in der HamnetDB an das 16-bit Root-AS gehängt.
- Bei der Migration kann in vielen Fällen die alte 32-bit AS-Nummer erhalten bleiben.
Die Transfernetze werden der Reihe nach in /29 Schritten angelegt und in der HamnetDB an das 16-bit Root-AS gehängt.
- Bei der Migration kann in vielen Fällen das alte Transfernetz durch Tausch von 224 → 148 übernommen werden.
Die Sitenetworks werden der Reihe nach in /27 Schritten angelegt, wobei nach jedem /27 ein weiteres /27 freigelassen wird damit ein Standort bei Bedarf auf ein /26 expandieren kann.
Hinweis: Man kann pro AS 16 Standorte mit je /27 plus einer /27 Lücke unterbringen bevor man anfangen muss, die Lücken zu füllen. Die Lücken werden so gefüllt dass die Standorte mit geringster Erweiterungswahrscheinlichkeit nebeneinander liegen.
- Bei der Migration kann in vielen Fällen das alte Sitenetwork durch Tausch von 225 → 149 übernommen werden.
Hat ein Standort mehrere Userzugänge kann man am Router alle Userzugänge in eine Bridge legen und gemeinsam über ein einziges Usernetz mit einem eigenen DHCP-Server vom Router versorgen. Dadurch kann man eine Menge IP-Range sparen.

Q: Welche Reihenfolge sollte bei der Umstellung beachtet werden?

A: Es bietet sich an zuerst den Backbone auf die neuen IP-Adressen umzustellen.
Achtung Hostnamenwechsel bei DNS-Einträgen: „lnk-<gegenstelle>.<eigenes rufzeichen>“ wird „trx-<gegenstelle>.<eigenes rufzeichen>“

# Beispiel für ein Linktransfernetz nach neuer Syntax
# Beispiel-Link von DB0WAL zu DB0HAT
# Beispiel-Transfernetz 44.148.26.0/29
#
44.148.26.1    bb-db0hat.db0wal.as64633.de.ampr.org   # Router  DB0WAL
44.148.26.2    trx-db0hat.db0wal.as64633.de.ampr.org  # LinkTRX DB0WAL
44.148.26.5    trx-db0wal.db0hat.as64633.de.ampr.org  # LinkTRX DB0HAT
44.148.26.6    bb-db0wal.db0hat.as64633.de.ampr.org   # Router  DB0HAT

Routerkonfiguration

Q: Wie gehen wir im HAMNET damit um, dass das AMPRNet jetzt nicht mehr aus einem einzigen 44.0.0.0/8 besteht?

A: Das AMPRNet besteht nur noch aus den beiden Netzblöcken 44.0.0.0/9 und 44.128.0.0/10. Einige Netze aus dem verbliebenen AMPRNet werden auch von Funkamateuren direkt im Internet betrieben (direct-BGP) was zu Inkompatibilitäten führt. Wir unterscheiden zwischen Routern im HAMNET-Backbone (diese lernen alle aktiven Routen des AMPRNet und haben daher kein Problem) und den Routern der Endnutzer. Bei den Endnutzern besteht häufig die Anforderung eine statische Route „zum HAMNET“ im Router des lokalen LANs eintragen zu müssen. Offiziell besteht das AMPRNet nicht mehr aus dem einzelnen Netz 44.0.0.0/8, sondern aus den beiden Netzen 44.0.0.0/9 und 44.128.0.0/10. Nach ausführlicher Diskussion auf der HAMNET-Tagung in Passau empfiehlt die IP-Koordination DL aktuell folgende Netzrouten für das HAMNET zu verwenden:

44.130.0.0/16 Deutschland
44.142.0.0/15 Österreich/Schweiz
44.148.0.0/15 Deutschland
44.186.0.0/15 Europa
44.224.0.0/15 temporär, bis das HAMNET in DL komplett umgezogen ist

Die IP-Koordination DL wird die allgemeine Empfehlung immer wieder prüfen und ggf. anpassen.

Q: Wie vermeide ich dass mein Knoten Pakete ins Internet schickt, wenn Hosts aus dem HAMNET angesprochen werden , aber gerade nicht erreichbar sind?

A: An Deinem HAMNET-Standort ist eine Defaultroute ins Internet aktiv. Die IP-Koordination DL empfiehlt die Netze an jedem HAMNET-Router mit je einer sogenannten „Blackhole“-Route zu terminieren. Beispiel an einem Mikrotik-Router: „ip route add dst-address=44.148.0.0/15 type=blackhole“. Die Route wird dann in der Routing-Tabelle mit dem Flag „B“ angezeigt und bewirkt, dass alle Pakete in Richtung 44.148.0.0/15 verworfen werden, solange keine spezifischeren Routen über das BGP-Routing des HAMNET gelernt werden. Wir empfehlen keine Blackhole-Routen ueber das gesamte AMPRNet zu legen (44.0.0.0/9 und 44.128.0.0/10), da sonst einige Ziele im Internet nicht mehr erreicht werden können.

Q: Ich nutze an meinem HAMNET-Knoten aus dem /27-Sitenetwork aktuell nur das /28-Servicenetz und nicht das /28-Usernetz. Habe ich etwas zu beachten?

A: Prinzipiell ist dafür Sorge zu tragen, dass die über das lokale IP-Netzannouncement ins HAMNET angezogenen IP-Pakete auch passend weitergeleitet oder „geerdet“ werden. Durch die in der vorherigen Antwort erwähnte „Blackhole“-Route wird diese „Erdung“ sichergestellt.

Tipps und Tricks

Q: Ich weis nicht wo ich anfangen soll, gibt es irgendwo Beispieldokumentationen?

A: Die genaue Planung eines AS ist von vielen regions- und standortspezifischen Aspekten abhängig. Sicher wird es keine Patentlösung geben, mit der man jedes beliebige AS aufziehen kann. Ist das Nachbar-AS schon fertig? Wie haben die das gemacht? Recht verbreitet im Amateurfunk scheint auch eine gewisse Abneigung experimentierfreudiger Admins zu sein, unter Zeitdruck etwas für andere lesbar zu dokumentieren Oft hilft ein gezielter Blick auf fertig umgezogene AS in der HamnetDB. Bis sich dort mehr findet, können einige Anregungen aus ersten Dokumentationsversuchen anderer AS gewonnen werden. Beispiele wären vielleicht AS64627, AS64633, AS64654, AS64663, AS64666. Sicher werden andere folgen und ganz sicher sind alle Dokus niemals fertig und fehlerfrei.

Q: Was mache ich, wenn ich in einer Region zwar die Router betreue, aber die Geräte an den Standorten nicht?

A: Die neuen IP-Netze können parallel zu den alten IP-Netzen konfiguriert werden. Kommt ein DHCP-Server zum Einsatz, kann die Umstellung der lokalen Geräte über die Anpassung des DHCP-Servers schnell durchgeführt werden.

Q: Welche weiteren Tipps und Tricks sind empfehlenswert?

A: Die folgende Sammlung erhebt nicht den Anspruch auf Vollständigkeit:

Der Router im Servicenetz ist immer unter der ersten IP-Adresse erreichbar und trägt den Hostnamen „router.<eigenes rufzeichen>“. Für das lokale Service-Netz bietet er unter dieser IP-Adresse einen DNS-Server an („Allow Remote Requests“ in den DNS-Settings am Router aktivieren)
Der Router im Usernetz ist immer unter der ersten IP-Adresse erreichbar und trägt den Hostnamen „gw.<eigenes rufzeichen>“. Für das lokale Service-Netz bietet er unter dieser IP-Adresse einen DNS-Server an („Allow Remote Requests“ in den DNS-Settings am Router aktivieren)
Ist „Allow Remote Requests“ aktiviert, muss darauf geachtet werden, dass der Port 53 aus dem Internet nicht ansprechbar ist (DNS Amplification Attack → Firewall!)
Als DNS-Server kann der Server der IP-Koordination DL in der HamCloud genutzt werden: 44.148.228.53 bzw. ns.hc.r1.ampr.org
Als NTP-Server kann der Server der IP-Koordination DL in der HamCloud genutzt werden: 44.148.224.123 bzw. ntp.hc.r1.ampr.org

⁴⁾

Hinweis: DNS-Einträge sind nicht an das Rufzeichen des HAMNET-Standortes gebunden.

netzplanung

Anonymous (anonymous@undisclosed.example.com) — 2019-10-24T16:28:50+00:00

Netzplanung

Unter AS-Nummern finden sich die aktuellen Netz-Zuweisungen von Backbone und User/Services.

Zwar lassen sich beliebige Netze (sogar IPv6) an ein AS (das sich durch seine eindeutige AS-Nummer auszeichnet) aufhängen. Doch wir halten es für sinnvoll, Bereiche für

  1. ein Backbone-Netz der Router/Switche innerhalb des AS und
  2. für User und Dienste einzuplanen.

Diese Netze können auf mehrere Standorte innerhalb eines AS weiter unterteilt werden (subnetting).

Wir haben in einem ersten Schritt pro AS ein /24 Backbone-Netz und ein /22 Netz für User/Services eingeplant. Diese lassen sich im freien Bereich unseres neuen, exklusiv für das HamNet zugeteilten 44.224/15 Netzes unterbringen.

Dieses 44.224/15 Netz lässt sich so aus z.B. dem old-generation PR-Netz durch einen einzigen Routingeintrag bequem routen. Wir empfehlen, durch Scripte zuzusichern, dass der Link am Übergabepunkt funktioniert und im Fehlerfall diese Netz-Route automatisch auszutragen (gleiches gilt für den Import der old-generation PR Zone ins Next-Generation-Netz). BackBone-Netz

Der Backbone-Bereich ist für die Router und Switches im next-generation Netz gedacht. Es dient zur Vermittlung der Routen über Routingprotokolle (internes iBGP, OSPF o.ä.). Dienste stehen nicht zur Verfügung. Ggf. kann der Zugriff auf die Router in diesem Netz gefiltert werden (z.B. nur icmp erlauben), wenn solche Sofort-Maßnahmen z.B. wegen Sicherheitslücken erforderlich sind.

Die Backbone Adressen tauchen im Traceoute auf. Deshalb kann man nicht mit RFC1918-Adressen 7) arbeiten, weil deren ICMP-Antworten und -Meldungen sonst ggf. an anderer Stelle im Netz gefiltert würden.

TODO: Überlegung, ob ein Backbone-Netz auch über 2 AS geplittet werden kann (Ziel: schonender Umgang mit Resourcen. Nachteil: unübersichtliche Konfiguration). Routing statt Bridging innerhalb des AS. Transfer-Netze zur eBGP Übergabe in Nachbar-AS.

Weitere Überlegungen hier: Beispiel BackBone-Netz. User/Services-Netz(e)

Der User/Services Bereich ist für die Dienste am Standort gedacht.

  Services: DNS, Webserver, Mailserver, DHCP, NTP, Gateway ins klassische PR Netz, D-Star-Rechner, EchoLink-Rechner, Asterisk-Server, IP-Steckdose, usw..
  User: Erhalten Zugang über DHCP

Für diese Anwendung haben wir für jedes AS durch Zuteilung eines /22 Netzes viermal so viel IP-Adressen eingeplant wie für den Backbonebereich, der pro AS aus einem /24 Netz besteht..

Es ist auch kein Problem, bei Adressknappheit weitere bisher nicht genutzte Netzsegmente aus dem old-generation-Bereich seiner Region zu benutzen (z.B. haben die Berliner noch zwei aufgesparte Bereiche).

Weitere Überlegungen hier: Beispiel User/Services-Netz. Anycast

Aktuell besprechen wir noch Strategien wie beispielsweise Anycast-Adressen in einem ausgezeichneten Adressbereich, um die Erreichbarkeit von Diensten wie Nameserver oder Proxy sicherzustellen. Dies hätte auch den Charme, dass man - egal wo in DL man ins Netz geht - mit seinem Nameserver-Eintrag immer den am besten erreichbaren Nameserver anspricht.

Thema IPv6: leider gibt es noch kein IPv6 Netz für den Amateurfunk. Bei unseren Netzen neuer Generation sollten wir von Beginn an IPv6-Fähigkeit im Auge behalten.

start

Anonymous (anonymous@undisclosed.example.com) — 2026-01-04T20:58:28+00:00

HAMNET

Dezentrales Hosting

Das HAMNET funktioniert, ähnlich wie das Internet, als dezentral strukturiertes Netzwerk. Zahlreiche Ressourcen und Dienste werden, regional verteilt, von vielen engagierten Betreibergruppen bereit gestellt und stehen zum überwiegenden Teil allen am HAMNET Teilnehmenden zur allgemeinen Nutzung zur Verfügung. Aufgrund der dezentralen Struktur und unterschiedlicher Motivationslage der einzelnen Betreibergruppen sind Umfang und Qualität der angebotenen Informationen relativ dynamisch und haben einen weitgehend experimentellen Charakter. Damit ein solches Netz störungsfrei funktionieren kann, müssen bei Aufbau, Planung und Betrieb des Backbones bestimmte Anforderungen hinsichtlich Hardware, Software, Routing und IP-Netzen eingehalten werden. Entwicklung, Planung, Bereitstellung und Betrieb gehören zu den Kernaufgaben der DL-IP-Koordination HAMNET.

Inhalte finden

Wegen seiner dezentralen Struktur und der Dynamik im Wachstum ergibt sich für Teilnehmende im HAMNET die Schwierigkeit, gewünschte Inhalte oder Angebote zu finden. Das Werkzeug der Wahl ist normalerweise ein Webbrowser. Informationen lassen sich auf drei Ebenen finden, die sich hinsichtlich Umfang, Treffergenauigkeit und Aktualität deutlich unterscheiden.

Informationsquelle	Genauigkeit	Aktualität	Beispiele
Linklisten	manuell gepflegt / hohe Fehlerquote	keine zeitnahe Aktualisierung	hier oder hier
Indexserver	manuell gepflegt / mittlere Fehlerquote	keine zeitnahe Aktualisierung	hier
Suchmaschine	automatisches Crawlen / geringe Fehlerquote	ständige Aktualisierung	HAMNET Suchmaschine

Routing im HAMNET

Das HAMNET ist ein in sich geschlossenes, TCP/IP-gestütztes Datennetz. Es steht dem Amateurfunkdienst exklusiv zur Verfügung. HAMNET ist kein Internetersatz! Es stellt die Kommunikation über schnelle Richtfunkstrecken in den Vordergrund. Jeder Funkamateur kann an diesem Netz teilnehmen. Derzeit werden je nach Funkstrecke und eingesetzter Technik Übertragungsraten zwischen 1MBit/s und 1GBit/s erreicht.

BGP Protokoll

Im HAMNET wird, genau wie im Internet, BGP als automatisches Exterior-Gateway-Protokoll eingesetzt. Es verbindet die autonomen Systeme (AS) miteinander. Im HAMNET werden solche AS durch eine zusammenhängende Region abgebildet. In einem solchen HAMNET-AS befinden sich mehreren Standorte (Sites), die über mindestens einen BGP sprechenden Router je Standort miteinander verbunden sind. Diese Router-Gruppe wird zusammen von einem oder mehreren AS-Maintainern administriert. Beim BGP-Protokoll muss aus technischen Gründen jedem AS zwingend eine eineindeutige AS-Nummer zugewiesen werden.

AS-Nummern

Seit August 2009 hat die DL-IP-Koordination die Koordination und Vergabe der AS-Nummern (ASN) innerhalb des deutschen HAMNET übernommen. Jedes AS im HAMNET erhält eine 16-bit breite AS-Nummer. Innerhalb dieses Parent-AS stehen für die einzelnen Sites bzw. Standorte einhundert weitere 32-bit-AS-Nummern zur Verfügung. Die an den Parent-AS aufgehängten IP-Netze für Backbone und User/Services werden zusammen mit den AS-Nummern von der DL-IP-Koordination koordiniert und zugewiesen (allocated & assigned).

IP-Netze

Für Deutschland ist der alte IPv4-Netzblock 44.130.0.0/16 fest zugewiesen. Zusätzlich hat Deutschland den IPv4-Nummernblock 44.148.0.0/15 von der ARDC für die Nutzung im HAMNET und der HAMCLOUD exklusiv zugewiesen bekommen. Die Nutzung für die einzelnen Bereiche wurde von der DL-IP-Koordination wie folgt festgelegt:

IP Netzblock	/24-Netze	Zuteilung	Nutzung
44.130.0.0/16	256	HAMNET	PR/NPR/Special Use
44.148.0.0/17	128	HAMNET	Backbone/Special Use
44.148.128.0/17	128	HAMCLOUD	Datacenters/Services
44.149.0.0/16	256	HAMNET	User/Services/Special Use

Domain Name System

Das deutsche HAMNET startete im Jahr 2009 mit einem Regionalzonenkonzept unterhalb der Domain *.ampr.org. Durch organisatorische und technische Umstrukturierungen seitens der ARDC war ab ca. 2023 die automatisierte Pflege der HAMNET-Domains und IP-Adressen auf den autoritativen DNS-Servern nicht mehr möglich. Die zugewiesenen Netze wurden seitens der ARDC delegiert und werden seit 2023 auf eigenen DNS-Systemen verwaltet und mit der HamnetDB synchronisiert. Im Zuge dieser Umstellung wurde das Regionalzonenkonzept unterhalb *de.ampr.org zugunsten einer Unterscheidung der technischen Verwendung der eingesetzten IP-Netze aufgegeben. Es werden drei verschiedene Anwendungsbereiche unterschieden:

Subdomain	Verwendung	Anmerkung
*.hamnet.radio	Hosts im HAMNET	nicht vom Internet aus erreichbar
*.hamnet.cloud	Hosts in der HamCloud	nicht vom Internet aus erreichbar
*.hamnet.network	Hosts im Internet	vom Internet aus erreichbar (IP auch außerhalb von 44-Net)

Host- und Domainnamen

hamnet.radio

In der Regel werden alle Geräte innerhalb des rf-basierten HAMNET in diese Zone eingeordnet. Diese Geräte sind nur im HAMNET/HamCloud und NICHT vom Internet aus erreichbar. Hostnamen mit den zugehörigen IPs können von registrierten Maintainern über die HamnetDB verwaltet werden. Auch CNAME-Konstrukte sind möglich. In 5min Intervallen werden Änderungen in der HamnetDB mit den zugehörigen Master-DNS automatisch synchronisiert. Dabei wird im DNS sowohl die Vorwärts- als auch die Rückwärts-Auflösung generiert. Die zu verwendenden IP-Netze sind zuvor von der IP-Koordination DL an die Parent-AS delegiert worden. Die Syntax der Namensvergabe innerhalb der hamnet.radio-Zonendatei muss mindestens das zugeteilte Rufzeichen der Site beinhalten.

Das folgende Beispiel zeigt einen FQDN (Full Qualified Domain Name), also die vollständige Bezeichnung für einen Router am Standort von DB0RES:

       router.db0res.hamnet.radio
       |       |      |       |  
       |       |      |       +----------  RADIO Gerät steht im rf-basierten HAMNET
       |       |      +------------------  HAMNET Subdomain kennzeichnet Zugehörigkeit zum HAMNET
       |       +-------------------------  CALLSIGN ohne SSID vom jeweiligen STANDORT der Site (Zuteilung BNetzA)
       +---------------------------------  HOSTNAME für ein Gerät, einen Dienst, Router, eine IP-Steckdose etc.

hamnet.cloud

Diese Geräte sind innerhalb der HamCloud untergebracht und per Draht/Internet/VPN direkt miteinander verbunden. Dazu gehören Hardware, virtuelle Maschinen und VPN-Clients. Sie sind über Gateways nur innerhalb HAMNET/HamCloud und NICHT direkt vom Internet aus erreichbar. Die Zone ist in der HamnetDB dokumentiert. Die Administration erfolgt durch die DL-IP-Koordination. Beispiele:

       de.hamnet.cloud     - diese Website von HAMNET/HamCloud aus
       next.hamnet.cloud   - Nextcloud der DL-IP-Koordination
       search.hamnet.cloud - Suchmaschine fuer das HAMNET (in Erprobung)

hamnet.network

Diese Zone enthält Dienste und Services, die auch inbound vom Internet aus erreichbar sein müssen. Die FQDN (Full Qualified Domain Name) können auf jede beliebige, im Internet geroutete IP-Nummer auflösen. Sie sind daher möglicherweise innerhalb von HAMNET/HamCloud nicht, sondern nur direkt vom Internet aus erreichbar. Die Administration erfolgt durch die DL-IP-Koordination. Beispiele:

       de.hamnet.network       - diese Website vom Internet aus
       cloud.de.hamnet.network - Nextcloud der DL-IP-Koordination
       vpn.hamnet.network      - VPN-Verwaltung

DNS Server

Die Master-DNS für die drei Domains hamnet.radio, hamnet.cloud und hamnet.network werden an verschiedenen Stellen im Internet betrieben und von der DL-IP-Koordination administriert. Das ermöglicht Resilienz gegenüber regionalen Ausfällen des Internet. Dank der Delegation der IP-Netze durch die ARDC ist auch eine Reverse-Auflösung möglich (PTR Records). Alle Informationen sind weltweit abrufbar. Die DL-IP-Koordination betreibt in seinen drei regional verteilten Datacentern drei Caching-DNS-Server, die über die gemeinsame Anycast IP-Adresse 44.148.228.53 erreichbar sind. Mit Hilfe der im HAMNET verteilten, zahlreichen HamCloud-Bordergateways ist aus dem HAMNET heraus eine redundante Erreichbarkeit mit guten Antwortzeiten gewährleistet. Die Nameserver sind universell nutzbar, denn sie können für alle Clients aus dem HAMNET und der HamCloud neben den Anfragen an die eigenen Zonen „hamnet.radio“, „hamnet.cloud“ und „hamnet.network“ auch alle anderen Anfragen beantworten.

Hostname: ns.hamnet.cloud
IP-Adresse: 44.148.228.53
UDP-Port: 53
TCP-Port: 53

Verantwortlich: DL-IP-Koordination HAMNET - Thomas Osterried, DL9SAU

Um den DNS-Traffic in einer Region zu optimieren, wird den Parent-AS empfohlen, innerhalb ihrer Region ein oder zwei weitere, gut erreichbare Cache-DNS einzurichten, die auf den bereitgestellten Anycast-DNS aufsetzen und/oder - falls ein Internetgateway am Standort vorhanden - die im Internet angebotenen DNS-Dienste zu nutzen.