Ursachen (Aggregation) 1

Abbildung 55: Kumulative Verteilungsfunktion der RTTs unmittelbar vor der Schleifenbildung und unter normalen Bedingungen (2004) [80]

z.B. 10.1.0.0/24 bis 10.1.15.0/24 zu einem generelleren Netz z.B. 10.1.0.0/20. Dieses generellere Netz wird an alle Nachbarn propagiert.

Abbildung 56: Route Aggregation [62]

Im Beispiel in Abbildung 56 würde die Routing Tabelle von Router Z ohne Route Aggregation jedes einzelne Präfix von 10.1.0.0/24 bis 10.1.15.0/24 beinhalten. Mit Route Aggregation würde nur das generellere Präfix 10.1.0.0/20 eingetragen. Wird ein Aggregat in einem Router gebildet (Router Y), werden alle spezifischeren Präfixe als Child Route vorgehalten. Das Aggregat wird nur propagiert, wenn mindestens eine Child Route vorhanden ist. Route Aggregation kann durch statische Routen oder dynamische Features des Routing-Protokolls ausgelöst werden. Alle Routing-Protokolle (BGP, RIP, OSPF usw.) unterstützen automatische Mechanismen, um Routen zu aggregieren. Manche Implementierungen aktivieren diese in der Standardeinstellung [62].

Es gibt mehrere Gründe, warum Routen aggregiert werden [62]:

 Route Aggregation wird im Zusammenhang mit CIDR benutzt, um die Routing-Tabellen wie im obigen Beispiel zu minimieren.

 Route Aggregation maskiert Route Flaps in den spezifischeren Netzen. Wenn im obigen Beispiel Router X0 aufgrund eines Hardware-Fehlers beginnt sein Netz

kontinuierlich im Wechsel von funktionstüchtig zu funktionsuntüchtig zu propagieren, bleiben diese Flaps für Router Z aufgrund der Aggregation in Y verborgen.

 Letztlich kann Route Aggregation noch dazu benutzt werden, um netzwerkweite Designziele umzusetzen. Im Beispiel in Abbildung 57 hat das Enterprise Netzwerk zwei ISPs (ISP A und ISP B). Traffic aus dem Internet für 20.1.0.0/16 soll durch den Router Seattle fließen. Verkehr für 20.0.0.0/16 soll den Weg über Router Pittsburgh nehmen. Zusätzlich soll Verkehr aus dem Internet den jeweils anderen Pfad als Backup nehmen. Um dies zu erreichen, propagieren beide Router das generellere 20.0.0.0/15 Präfix und das jeweilige spezifischere Präfix (20.1.0.0/16 für Router Seattle oder 20.0.0.0/16 für Router Pittsburgh). Sind Netzwerke über mehrere Border Router mit den/dem Provider(n) verbunden, kann Route Aggregation genutzt werden, um Load Balancing zu erreichen. Auch hier wird wieder das generelle und spezifischere Präfix gleichzeitig propagiert. Weiterhin kann Route Aggregation die interne Netzstruktur maskieren.

Abbildung 57: Backup-Pfad mittels Route Aggregation [62]

Das nächste Beispiel verdeutlicht die Entstehung einer persistenten Schleife.

Abbildung 58: Persistente Schleife durch Aggregation [62]

Im Beispiel in Abbildung 58 aggregiert Router Y seine Teilnetze 128.2.1.0/24, 128.2.2.0/24 und 128.2.5.0/24. Das Aggregat 128.2.0.0/16 wird an Router X propagiert. Die Ursachen für die Entstehung einer Schleife liegen zum einen in der Default Route (kann statisch oder per Routing-Update installiert werden) von Y zu X und in der Tatsache, dass nicht alle Subnetze des propagierten Aggregats erreichbar sind. Sendet X Pakete für ein nicht vergebenes Subnetz z.B. 128.2.3.0/24 an Router Y , hat Router Y keinen Eintrag in seiner Routing-Tabelle für 128.2.3.0/24 und sendet den Verkehr über seine Default Route an Y zurück. Die Pakete traversieren die persistente Schleife bis zum Ablauf der TTL. Zwar beeinflusst die persistente Schleife Verkehr für vergebene und damit erreichbare Subnetze nicht direkt, das Traversieren der Pakete in der Schleife jedoch erhöht die Auslastung der Router X und Y und kann damit zu einem Stau führen [62].

Um obiges Szenario zu verhindern wird empfohlen, eine sogenannte Sink Route zu installieren. Eine Sink Route verwirft alle Pakete, die an ein nicht vergebenes Subnetz gerichtet sind. Im obigen Beispiel würde ein Eintrag 128.2.0.0/16 der auf ein Null Interface verweist, alle Pakete für nicht vergebene Subnetze verwerfen und damit die persistente Schleife verhindern [62].

Im vorigen Beispiel entsteht die Schleife nahe der Zieldomain und weist eine Länge von zwei Hops auf. Analog lässt sich dieses Szenario auf persistente Schleifen mit mehr als zwei Hops erweitern.

Abbildung 59: Persistente Schleife mit mehr als zwei Hops [59]

Im Beispiel in Abbildung 59 ist Customer C mit mehreren Providern verbunden. Eingehender Verkehr soll über Provider P gelangen, ausgehender über Provider A versendet werden.

Customer C propagiert das aggregierte Präfix 18.1.0.0/16 an Provider P. Um ausgehenden Verkehr über Provider A zu leiten, installiert Customer C eine Default Route 0.0.0.0/0 über Provider A. Pakete für z.B. 18.1.3.0/24 werden von Provider P an Customer C gesendet. Da Customer C das Subnetz nicht unterhält und keine Sink Route installiert hat, werden die Pakete über die Default Route an Provider A gesendet. Provider A sendet die Pakete weiter, sodass sie evtl. über mehrere Hops wieder Provider P erreichen. Eine persistente Schleife mit mehr als zwei Hops ist entstanden [59].

In [59] werden Kriterien aufgestellt, um zu prüfen inwieweit Route Aggregation in Verbindung mit Default Routes und fehlenden Sink Routes für die Entstehung von persistenten Schleifen verantwortlich ist. Im Folgenden wird dieser Umstand allgemein als fehlerhafte Konfiguration beschrieben:

1. Ein Netzwerk propagiert ein aggregiertes Präfix ins Internet. Pfade zu manchen Subnetzen weisen persistente Schleifen auf, Pfade zu anderen Subnetzen weisen wiederum keine persistenten Schleifen auf.

2. Pfade zu Subnetzen aus einer bestimmten Quelle weisen den gleichen Pfad im Internet auf, divergieren aber innerhalb des Netzwerks.

3. Es befindet sich ein fehlerhaft konfigurierter Router auf dem Pfad. Manche Pfade zu Subnetzen weisen persistente Schleifen auf, manche nicht.

In [59] wird folgender Algorithmus auf alle gefundenen persistenten Schleifen angewendet (siehe Kapitel 3.4.3.3):

1. Finde das globale Präfix p in BGP Routing-Tabellen, welches ein Supernet zu einem gefundenen Präfix mit persistenter Schleife darstellt.

2. Finde alle Traces in DA die zu Zieladressen von Präfix p führen und füge sie der Menge T(p) zu.

3. Zerlege T(p) in zwei Klassen T1(p) und T2(p) a. T1(p) enthält eine persistente Schleife b. T2(p) enthält keine persistente Schleife

4. Existiert ein Trace t1 aus T1(p) und ein Trace t2 aus T2(p), für die gilt a. Wenn t1 und t2 eine Interface Adresse r enthält und

b. r zu der persistenten Schleife gehört und

c. beide Pfade von der Quelle zum Ziel r in t1 und t2 identisch sind, dann KANN die persistente Schleife aufgrund fehlerhafter Konfiguration entstanden sein.

Es werden alle Präfixe, die in den Routing-Tabellen des Routeview-Projekts erscheinen mit diesem Algorithmus untersucht. Für 21% der persistenten Schleifen treffen alle Bedingungen zu [59].

Bedingung (4c) prüft, ob die Pfade identisch sind. Aufgrund von Paketverlusten, ICMP Rate Limiting oder Filtern können die Traces leichte Unterschiede aufweisen, obwohl die Pfade identisch sind.

Abbildung 60: Zwei Traces mit dem gleichen Weiterleitungspfad [43]

Im Traceroute zum Ziel 208.53.185.80 in Abbildung 60 wird von einem identischen Weiterleitungspfad ausgegangen. Aufgrund von Timeouts bei Hop 4 und Hop 8 weisen die Traces Unterschiede auf. In anderen Fällen unterscheiden sich zwei Traces nur in ein oder zwei Router Interfaces. Zum Beispiel kann aufgrund von Load Balancing Hop 16 im obigen Beispiel differieren. Aus diesen Gründen können eventuell manche persistente Schleifen aufgrund von fehlerhafter Konfiguration sich dem Algorithmus entziehen. Bedingung (4) aus dem Algorithmus wird deshalb in zwei Varianten aufgeweicht [59]:

 Variante 1: Die Idee hierbei ist, isolierte Unstimmigkeiten zu erlauben. Weisen zwei Traces einen Unterschied im Interface r2 auf, so müssen die Interfaces unmittelbar vorher (r1) und unmittelbar nachher (r3) identisch sein. Mit dieser Bedingung konnten 39% der persistenten Schleifen einer fehlerhaften Konfiguration zugeordnet werden.

 Variante 2: Die Bedingung (4c) wird vollständig entfernt. Traces müssen nun nicht mehr bis zum Router Interface r identisch sein. Mit dieser Bedingung konnten 50%

der persistenten Schleifen einer fehlerhaften Konfiguration zugeordnet werden.

Obige Aufweichungen könnten zu einer Überschatzung von persistenten Schleifen aufgrund fehlerhafter Konfiguration führen. Wichtig ist anzumerken, dass der Algorithmus notwendige aber nicht hinreichende Bedingungen formuliert. Wenn ein Netzwerk keine zusammenhängenden Subnetze verwendet und diese Präfixe einzeln propagiert werden, werden diese vom Algorithmus nicht gefunden, obwohl persistente Schleifen aufgrund von fehlerhafter Konfiguration trotzdem existieren können. Weiterhin kann ein Pfad nur Router Interfaces enthalten, die in keiner persistenten Schleife vorkommen. Aufgrund der Vergabe von Aliasen für Interfaces ist es dennoch möglich, dass ein Interface im Pfad in einer persistenten Schleife involviert ist [59].