Erläuterung
Ähnlich wie im Packet-Radio-System müssen auch im HAMNET (respektive im dahinterliegenden Backbone dafür) die Datenpakete ihre Ziele finden. Es ist im HAMNET unvermeidbar, das komplexe Mischtopologien (Stern, Ring) entstehen, welche bei der Linkstreckenplanung durch Österreich einem Routing - ähnlich dem Packet-Radio - bedürfen.
Die Pakete müssen oft mehrere „Hops“ überwinden. Pakete-Sender und Empfänger wechseln einander ständig ab. Daher müssen die Pakete duplex ihren Weg durch das Netz finden, damit eine Anwendung schlussendlich funktioniert.
Da händische Routeneintragungen in einem derart großem Netzwerk nicht mehr administrierbar sind, müssen Automatismen angewendet werden, welche das System möglichst rasch über die vorhandenen Zielnetze informieren. Dies beinhaltet die automatische Wegefindung von Alternativrouten, z.B.: bei Ausfall eines HF-Links oder bei einer Störung. Im bekannten Packet-Radio System bedient man sich etwa dem Flexnet-Routing.
Aufgrund verschiedener Untersuchungen wurde BGP „Border Gateway Protocol“ als das ideale Routing-Protokoll für den digitalen Backbone definiert.
Zielgruppe dieser Informationen: Sysops, Knotenbetreiber
Dokumentation
Diese Dokumentation gibt eine Einführung und Detaillierung der Konfigurationsmöglichkeiten im Backbone. Die Konfigurationsbeispiele und Richtlinien sind Ergebnisse aus den durch OE7BKH und OE7FMI nachgebauten Teststellungen und Versuchsaufbauten. (Dokumentation Stand 19.05.2009)
Betriebliche Notizen für Sysops
Folgende beitriebliche Notizen, zusätzlich zum Dokument ergaben sich aus dem bisher laufenden Betrieb.
Force Self im iBGP-Peer beachten
Bei allen Peers des iBGP (internal BGP) – also Peers zu Routern innerhalb der selben AS-Nummer (meist der Backbone im Bundesland, full mesh peers) muss bei der Funktion Nexthop Choice die Einstellung force self getätigt werden. Diese Einstellung muss auf allen Routern an den iBGP-Peers getätigt werden.
Dadurch substituiert der Router sich selbst als next hop (Gateway) dem nächsten iBGP Partner, und meldet nicht die IP-Adresse eines dahinterliegenden Routers aus dem eBGP als Gateway. Letzteres produziert beim Empfängerrouter Routen in das falsche Interface (meist ins Default Gateway), da der Router nicht weiß, wo das um einen Hop weiter entfernte Gateway liegt. Die Default-Einstellung ist offensichtlich "propogate" (Fortpflanzen) was nicht zum IP-Konzept passt bzw. ein darunterliegendes Routingprotokoll oder statische "Pflasterl" zusätzlich verlangen würde.
Bei den eBGP Peers scheint die Funktion „force self“ aus dem bisherigen Betrieb nicht erforderlich, und kann auf default belassen werden. Sollte sich aufgrund eines Firmwareupgrades an den Miktrotik-Boards hier etwas am Default-Wert ändern, wird eine Information hier eingebracht.
iBGP Peers nicht über verschiedene Netze ziehen
Gemäß IP-Konzept des HAMNETS OE kommt dies nicht vor.(iBGP Peers bleiben innerhalb des Backbone Netzes /24 pro Bundesland).
Bei der Sondersituation OE7XWI, in dem am Userrouter im Tal DB0FHN angebunden ist und ein Routing benötigt, konnte das full mesh-Peering nicht störungsfrei aus dem Usernetz in das Backbonenetz hochgezogen werden. (Trotz unterschiedlich versuchter Einstellungen und statisch geroutetem Unterbau für die Peers). Dem Userrouter wurde daher eine eigene AS-Nummer aus dem OE7-Freiraum gegeben. Zudem gibt es eine nicht unerwünschte PATH Verlängerung und AS-Path Bekanntgabe des speziellen Routers.
Das Problem ist eine Sondersituation und kommt im üblichen Backbone-Netz (Verlinkte Relaisstandorte mit ihren Routern) nicht vor. Dort verlaufen die iBGP-Peers innerhalb des selben /24 Netz.
Handling von Aggregates
Das Announcen von Aggregaten ist aus mehrern Gründen derzeit nicht vorgesehen. Detailrouten für detailliertere Netze erlauben auch mehr Übersicht und helfen bei der Fehlersuche.
Unabhängig vom derzeitigen oder zukünftigen Handling: Werden Aggregate announced, so müssen diese an allen AS-Grenzen (also wo eBGP Peers vorhanden sind) ident announced und summarized werden.
Sonst kann es dazu kommen, dass Datenpakete zu einem entfernten Punkt hinwärts über einen anderen Link verlaufen, als rückwärts. Wird dies nicht berücksichtigt kommt es dann dazu, dass einem externen Router (aufgrund eines Ringes) über einen anderen HF-Weg trotz Aggregat noch immer die detaillierten Routen gemeldet werden. Dies führt dazu, dass die Retourpakete an das Gateway der detaillierten Route zurückgesendet werden. Dabei wird dann ein anderer Weg beschritten, die Verbindung hakt oder kommt nicht zustande.
Daher müssen allfällige Aggregate an allen AS-Grenzen ident announced werden.
Derzeit sind Aggregate nicht vorgesehen und sollen auch nicht announced werden.
Diskussionen