5. Routing-Implementierungsaspekte

Routing-Implementierungsaspekte

Mit dem Wechsel von classful Netzwerknummern zu classless Präfixen ist es nicht möglich, die Netzwerksmaske aus dem führenden Bitmuster einer IPv4-Adresse abzuleiten. Dies hat Auswirkungen darauf, wie Routing-Informationen gespeichert und verbreitet werden. Netzwerkmasken oder Präfixlängen müssen explizit in den Routing-Protokollen übertragen werden. Die Interior-Routing-Protokolle wie OSPF [RFC2328], Intermediate System to Intermediate System (IS-IS) [RFC1195], RIPv2 [RFC2453] und das Enhanced Interior Gateway Routing Protocol (EIGRP) von Cisco sowie das Exterior-Routing-Protokoll BGP4 [RFC4271] unterstützen diese Funktion alle, da sie im Laufe der 1990er Jahre im Rahmen des Einsatzes des klassenlosen Inter-Domain-Routings entwickelt oder modifiziert wurden.

Ältere Interior-Routing-Protokolle wie RIP [RFC1058], HELLO und das Interior Gateway Routing Protocol (IGRP) von Cisco sowie ältere Exterior-Routing-Protokolle wie das Exterior Gateway Protocol (EGP) [RFC904] unterstützen den expliziten Transport der Präfixlänge/Maske nicht und können daher im Internet effektiv nicht anders als in sehr begrenzten Stub-Konfigurationen verwendet werden. Obwohl ihre Verwendung in einfachen, von Endstellen geerbten Konfigurationen angemessen sein kann, gelten sie als veraltet und sollten im mit dem globalen Internet verbundenen Transit-Netzen NICHT verwendet werden.

Ebenso müssen die Routing- und Forwarding-Tabellen in Layer-3-Netzwerkgeräten so organisiert sein, dass sowohl das Präfix als auch die Präfixlänge bzw. Maske gespeichert werden. Ein Gerät, das seine Routing/Forwarding-Informationen nach den geerbten Klasse-A/B/C- Netzwerk/Subnetz-Konventionen organisiert, kann nicht als korrekt im mit dem globalen Internet verbundenen Netzen funktionierend angesehen werden; die Verwendung eines solchen Geräts wird nicht empfohlen. Glücklicherweise werden heute sehr wenige solcher Geräte verwendet.

5.1. Regeln für die Routenankündigung

Das Forwarding im Internet erfolgt auf Basis der längsten Übereinstimmung. Dies bedeutet, dass Ziele, die hinsichtlich einer Routing-Domäne multi-homed sind, immer explizit in dieser Routing-Domäne angekündigt werden müssen (d. h., sie können nicht zusammengefasst werden). Wenn ein Netz multi-homed ist, müssen alle seine Pfade zu einer Routing-Domäne, die in der Hierarchie der Netze „höher“ liegt, dem „höheren“ Netz bekannt sein.
Ein Router, der eine aggregierte Route für mehrere spezifischere Routen erzeugt, muss Pakete verwerfen, die mit der aggregierten Route übereinstimmen, aber mit keiner der spezifischeren Routen. Mit anderen Worten sollte der „Next-Hop“ für die aggregierte Route das Null-Ziel sein. Dies ist notwendig, um die Bildung von Forwarding-Schleifen zu verhindern, wenn einige von der Aggregation abgedeckte Adressen nicht erreichbar sind.

Beachten Sie, dass bei Ausfällen ein partielles Routing des Traffics zu einer Endstelle, die ihren Adressraum von einem Dienstanbieter bezieht, aber tatsächlich nur über einen anderen erreichbar ist (d. h. der Fall einer Endstelle, die den Dienstanbieter gewechselt hat), auftreten kann, weil dieser Traffic entlang des von der aggregierten Route angekündigten Pfads weitergeleitet wird. Regel Nr. 2 verhindert die falsche Zustellung von Paketen, indem dieser Traffic vom Ankündiger der aggregierten Route verworfen wird, aber die Ausgabe von „traceroute“ und ähnlichen Werkzeugen lässt vermuten, dass ein Problem innerhalb dieses Netzes und nicht in dem Netz besteht, das das spezifischere Präfix nicht mehr ankündigt. Dies kann die verwirren, die Konnektivitätsprobleme diagnostizieren wollen; siehe das Beispiel in Abschnitt 6.2 für Details. Eine Lösung für dieses wahrgenommene „Problem“ liegt außerhalb des Rahmens dieses Dokuments; sie liegt in einer besseren Schulung der Nutzer/Betreiber-Gemeinschaft und nicht in der Routing-Technologie.

Eine Implementierung, die diesen Regeln folgt, muss auch verallgemeinert sein, sodass eine beliebige Netzwerknummer und -maske für alle Routing-Ziele akzeptiert wird. Die einzige verbleibende Einschränkung ist, dass die Maske zusammenhängend bleiben muss. Beachten Sie, dass die degenerierte Route zum Präfix 0.0.0.0/0 als Standardroute verwendet wird und von allen Implementierungen akzeptiert werden MUSS. Darüber hinaus muss, um sich vor einer versehentlichen Ankündigung dieser Route über das Inter-Domain-Protokoll zu schützen, diese Route an eine andere Routing-Domäne nur dann ankündigt werden, wenn ein Router explizit dafür konfiguriert ist, nie als nicht konfigurierte „Standard“-Option.

5.2. Funktionsweise der Regeln

Regel Nr. 1 stellt sicher, dass der zum Forwarding verwendete Algorithmus zwischen Routing-Protokollen und Implementierungen konsistent ist. Multi-homed Netze werden immer explizit von jedem der Dienstanbieter angekündigt, über die sie geroutet werden, selbst wenn sie ein spezifischer Teil des Aggregats eines Dienstanbieters sind (wenn nicht, müssen sie eindeutig explizit angekündigt werden). Es könnte scheinen, als könnte der „primäre“ Dienstanbieter die multi-homed Endstelle implizit als Teil seines Aggregats ankündigen, aber das Longest-Match-Forwarding verhindert, dass dies funktioniert. Mehr Details finden sich in [RFC4116].

Regel Nr. 2 stellt sicher, dass keine Routing-Schleifen durch Aggregation entstehen. Betrachten wir eine Endstelle, der 192.168.64/19 von ihrem „übergeordneten“ Dienstanbieter zugewiesen wurde, der 192.168.0.0/16 besitzt. Das „übergeordnete“ Netz wird 192.168.0.0/16 an das „untergeordnete“ Netz ankündigen. Wenn das „untergeordnete“ Netz seine interne Erreichbarkeit zu 192.168.65.0/24 (das Teil seines Aggregats ist) verlieren würde, folgt der Traffic vom „übergeordneten“ zum „untergeordneten“ Netz mit Ziel 192.168.65.1 der vom „untergeordneten“ Netz angekündigten Route. Wenn dieser Traffic das „untergeordnete“ Netz erreicht, darf dieses jedoch der 192.168.0.0/16-Route NICHT zurück zum „übergeordneten“ Netz folgen, da dies eine Forwarding-Schleife erzeugen würde. Regel Nr. 2 besagt, dass das „untergeordnete“ Netz einer weniger spezifischen Route für ein Ziel, das mit einer seiner eigenen aggregierten Routen übereinstimmt, nicht folgen darf (im Allgemeinen wird dies implementiert, indem eine „discard“- oder „null“-Route für alle aggregierten Präfixe installiert wird, die ein Netz an ein anderes ankündigt). Beachten Sie, dass die Behandlung der „Standard“-Route (0.0.0.0/0) ein Sonderfall dieser Regel ist; ein Netz darf der Standardroute für Ziele, die Teil einer seiner aggregierten Ankündigungen sind, nicht folgen.

5.3. Hinweis zu Präfixfilterformaten

Systeme, die Routenankündigungen verarbeiten, müssen in der Lage sein zu überprüfen, ob die empfangenen Informationen gemäß den Richtlinien akzeptabel sind. Implementierungen, die Routenankündigungen filtern, müssen Masken oder Präfixlängen in den Filterelementen zulassen. Daher sahen Filterlemente, die früher wie folgt spezifiziert waren,

  accept 172.16.0.0

  accept 172.25.120.0.0

  accept 172.31.0.0

  deny 10.2.0.0

  accept 10.0.0.0

nun eher so aus:

  accept 172.16.0.0/16

  accept 172.25.0.0/16

  accept 172.31.0.0/16

  deny 10.2.0.0/16

  accept 10.0.0.0/8

Dies macht nur die Netzwerksmaske explizit, die in der Klasse-A/B/C-Klassifizierung der Netzwerknummern implizit war. Es ist auch nützlich, die Filterfähigkeit zu verbessern, um die Übereinstimmung mit einem Präfix und allen spezifischeren Präfixen mit demselben Bitmuster zuzulassen; glücklicherweise wurde diese Funktion von den meisten im Internet verwendeten Geräteherstellern implementiert.

5.4. Verantwortung für und Konfiguration von Aggregation

Unter normalen Umständen hat eine Routing-Domäne (oder ein „Autonomous System“), der bzw. dem eine Menge von Präfixen zugewiesen oder zugeteilt wurde, die alleinige Verantwortung für die Aggregation dieser Präfixe. Im üblichen Fall wird das AS in einem oder mehreren seiner Router eine Konfiguration installieren, um aggregierte Routen basierend auf spezifischeren Routen zu erzeugen, die seinem internen Routing-System bekannt sind. Diese aggregierten Routen werden im globalen Routing-System von den Border-Routern für die Routing-Domäne angekündigt. Die internen, spezifischeren Routen, die die aggregierten Routen überlappen, dürfen nicht global ankündigt werden. In einigen Fällen kann ein AS die Aggregationsverantwortung an ein anderes AS delegieren (z. B. ein Kunde könnte wünschen, dass sein Dienstanbieter aggregierte Routing-Informationen in seinem Namen erzeugt); in solchen Fällen wird die Aggregation von einem Router im zweiten AS gemäß den von ihm vom ersten empfangenen Routen durchgeführt, kombiniert mit konfigurierten Richtlinieninformationen, die beschreiben, wie diese Routen aggregiert werden sollen.

Beachten Sie, dass ein Dienstanbieter eine Aggregation der von einem anderen empfangenen Routen ohne explizite Vereinbarung vornehmen kann; dies wird „Proxy-Aggregation“ genannt. Dies kann ein nützliches Werkzeug sein, um die Menge an Routing-Zustand zu reduzieren, die ein AS transportieren und an seine Kunden und Nachbarn propagieren muss. Die Proxy-Aggregation kann jedoch auch unbeabsichtigte Folgen in der Traffic-Engineering erzeugen. Betrachten Sie, was passiert, wenn AS 2 und AS 3 beide Routen von AS 1 empfangen, aber AS 2 Proxy-Aggregation durchführt, während AS 3 dies nicht tut. Andere AS, die Transit-Routing- Informationen sowohl von AS 2 als auch von AS 3 empfangen, sehen eine inkonsistente Sicht der aus AS 1 stammenden Routing-Informationen. Dies kann eine unerwartete Verlagerung des Traffics zu AS 1 über AS 3 für die Kunden von AS 3 und alle anderen bewirken, die Transit-Routen von AS 3 empfangen. Da die Proxy-Aggregation unerwartete Folgen für Teile des Internets haben kann, die weder mit der Quelle der aggregierten Routen noch mit der aggregierenden Partei in Beziehung stehen, muss sie mit extremer Vorsicht verwendet werden.

Die Konfiguration der zu aggregierenden Routen ist eine Implementierung der Routing-Richtlinie und erfordert manuell gepflegte Informationen. Zusätzlich zu den Informationen, die für eine Menge routbarer Präfixe gepflegt werden müssen, ist die Aggregationskonfiguration im Allgemeinen nur eine oder zwei Zeilen, die den Bereich des zu aggregierenden IPv4-Adressblocks definieren. Eine Endstelle, die ihre eigene Aggregation durchführt, tut dies für Adressblöcke, die ihr zugeteilt wurden; eine Endstelle, die im Namen einer anderen aggregiert, kennt diese Information über eine Delegationsvereinbarung. Unter der Annahme, dass die derzeitige Best Practice für Netzwerkadministratoren darin besteht, Präfixlisten zum gegenseitigen Akzeptieren auszutauschen, führt die Konfiguration der Aggregationsinformationen zu keiner signifikanten zusätzlichen administrativen Belastung.

Die Erzeugung einer aggregierten Route wird im Allgemeinen entweder statisch oder als Reaktion auf das Lernen einer aktiven dynamischen Route für ein in der aggregierten Route enthaltenes Präfix spezifiziert. Wenn eine solche dynamische aggregierte Routenankündigung erfolgt, ist darauf zu achten, dass Routen nicht übermäßig hinzugefügt oder entfernt werden (das sogenannte „Flapping“ von Routen). Im Allgemeinen wird eine dynamische aggregierte Routenankündigung hinzugefügt, wenn mindestens eine Komponente des Aggregats erreichbar wird, und erst entfernt, wenn alle Komponenten unerreichbar werden. Richtig konfiguriert sind aggregierte Routen stabiler als nicht aggregierte Routen und verbessern so die Stabilität des globalen Routings.

Implementierungshinweis: Die Aggregation des „Klasse-D“-Adressraums (Multicast) liegt außerhalb des Rahmens dieses Dokuments.

5.5. Routenpropagierung und Routing-Protokoll-Aspekte

Vor dem anfänglichen Einsatz von CIDR bestand die übliche Praxis darin, über die Exterior-Routing-Protokolle (d. h. EGP oder BGP) gelernte Routen durch das Interior-Routing-Protokoll einer Endstelle (meist OSPF, IS-IS oder RIP) zu propagieren. Dies geschah, um sicherzustellen, dass konsistente und korrekte Ausgangspunkte für Traffic ausgewählt wurden, der an ein über diese Protokolle gelerntes Ziel gesendet werden sollte. Vier sich entwickelnde Effekte – das Aufkommen von CIDR, das explosive Wachstum des globalen Routing-Zustands, die breite Einführung von BGP4 und die Anforderung, vollständige Pfadinformationen zu propagieren – haben sich kombiniert, um diese Praxis obsolet zu machen. Um eine korrekte Pfadpropagierung sicherzustellen und eine inter-AS-Routing- Inkonsistenz zu verhindern (der Schleifenerkennungs-/präventionsmechanismus von BGP4 verlangt die Propagierung des vollständigen Pfads), müssen Transit-Netze das Interior BGP (iBGP) verwenden, um von anderen Dienstanbietern gelernte Routen sowohl innerhalb als auch über ihre Netze zu transportieren.