7. Routing-Konvergenzeigenschaften

Dieser Abschnitt betrachtet Routing-Konvergenzeigenschaften im vorgeschlagenen Design. Es wird argumentiert, dass Subsekunden-Konvergenz erreichbar ist, wenn die Implementierung schnelle Deaktivierung von EBGP-Peering-Sessions und zeitnahe RIB- und FIB-Updates bei Ausfall der zugehörigen Verbindung unterstützt.

7.1. Fehlererkennungszeiten

BGP verlässt sich typischerweise auf ein IGP, um Link- oder Knotenausfälle innerhalb eines AS zu umgehen, und setzt entweder ein abfragebasiertes oder ereignisgesteuertes Verfahren ein, um Updates zu IGP-Zustandsänderungen zu erhalten. Das vorgeschlagene Routing-Design nutzt kein IGP; verbleibende Mechanismen zur Fehlererkennung sind daher BGP-Keep-Alive-Timeout (oder ein anderer Keep-Alive-Mechanismus) und Link-Ausfall-Trigger.

Die ausschließliche Nutzung von BGP-Keep-Alives kann zu hohen Konvergenzverzögerungen in der Größenordnung mehrerer Sekunden führen (in vielen BGP-Implementierungen ist der minimale konfigurierbare BGP-Hold-Timer drei Sekunden). Viele BGP-Implementierungen können jedoch lokale EBGP-Peering-Sessions bei einem « link down »-Ereignis für die ausgehende Schnittstelle des BGP-Peerings beenden. Diese Funktion heißt mitunter « fast fallover ». Da Links in modernen Rechenzentren überwiegend Punkt-zu-Punkt-Glasfaser sind, wird ein physischer Schnittstellenausfall oft in Millisekunden erkannt und löst anschließend BGP-Rekonvergenz aus.

Ethernet-Links können Fehlersignalisierungs- oder -erkennungsstandards wie Connectivity Fault Management (CFM) gemäß [IEEE8021Q] unterstützen; dies kann die Fehlererkennung robuster machen. Alternativ können einige Plattformen Bidirectional Forwarding Detection (BFD) [RFC5880] unterstützen, um Subsekunden-Fehlererkennung und -signalisierung an den BGP-Prozess zu ermöglichen. Die Nutzung davon stellt jedoch zusätzliche Anforderungen an Hersteller-Software und ggf. Hardware und kann REQ1 widersprechen. Bis vor kurzem erlaubte [RFC7130] zuvor auch keine Erkennung des Ausfalls eines einzelnen Mitgliedslinks in einem LAG, was den Nutzen in einigen Designs eingeschränkt hätte.

7.2. Ereignisausbreitungszeiten

Im vorgeschlagenen Design sollte die Auswirkung des BGP MinRouteAdvertisementIntervalTimer (MRAI-Timer), spezifiziert in Abschnitt 9.2.1.1 von [RFC4271], bedacht werden. Gemäß Standard ist es erforderlich, dass BGP-Implementierungen aufeinanderfolgende BGP-UPDATE-Nachrichten um mindestens MRAI Sekunden auseinanderhalten, oft ein konfigurierbarer Wert. Die ersten BGP-UPDATE-Nachrichten nach einem Ereignis mit zurückgezogenen Routen sind von diesem Timer üblicherweise nicht betroffen. Der MRAI-Timer kann erhebliche Konvergenzverzögerungen verursachen, wenn ein BGP-Speaker auf den neuen Pfad von seinen Peers « wartet » und keine lokale Backup-Pfadinformation hat.

In einer Clos-Topologie hat jeder EBGP-Speaker typischerweise entweder einen Pfad (Tier-2-Geräte akzeptieren keine Pfade von anderen Tier-2 im selben Cluster wegen gleicher ASN) oder N Pfade für dasselbe Präfix, wobei N sehr groß ist, z. B. N=32 (ECMP-Fan-out zur nächsten Ebene). Fällt daher ein Link zu einem anderen Gerät aus, von dem ein Pfad empfangen wurde, gibt es entweder gar keinen Backup-Pfad (z. B. aus Sicht eines Tier-2-Switches, der den Link zu einem Tier-3-Gerät verliert), oder das Backup ist sofort im BGP Loc-RIB verfügbar (z. B. aus Sicht eines Tier-2-Geräts, das den Link zu einem Tier-1-Switch verliert). Im ersten Fall verbreitet sich die BGP-Withdrawal-Ankündigung ohne Verzögerung und löst Rekonvergenz auf betroffenen Geräten aus. Im zweiten Fall wird der beste Pfad neu bewertet und die lokale ECMP-Gruppe für das neue Next-Hop-Set geändert. War der BGP-Pfad zuvor als bester Pfad gewählt, wird ein « implicit withdraw » per BGP-UPDATE gesendet, wie in Option b in Abschnitt 3.1 von [RFC4271] beschrieben, weil sich das BGP-AS_PATH-Attribut ändert.

7.3. Auswirkung von Clos-Topologie-Fan-outs

Clos-Topologien haben große Fan-outs, was in einigen Fällen die « Oben-nach-Unten »-Konvergenz beeinflussen kann, wie in diesem Abschnitt beschrieben. Fällt ein Link zwischen Tier-3- und Tier-2-Gerät aus, sendet das Tier-2-Gerät BGP-UPDATE-Nachrichten an alle stromaufwärtigen Tier-1-Geräte und zieht betroffene Präfixe zurück. Die Tier-1-Geräte leiten diese Nachrichten wiederum an alle stromabwärtigen Tier-2-Geräte weiter (außer dem Ursprung). Tier-2-Geräte außer dem Ursprung des UPDATE sollten dann warten, bis ALLE stromaufwärtigen Tier-1-Geräte eine UPDATE-Nachricht gesendet haben, bevor sie betroffene Präfixe entfernen und entsprechende UPDATE stromabwärts zu den angeschlossenen Tier-3-Geräten senden. Führen das ursprüngliche Tier-2-Gerät oder die weiterleitenden Tier-1-Geräte Verzögerungen in ihren UPDATE-Ankündigungen ein, kann das zu UPDATE-« Dispersion » führen, die mehrere Sekunden dauern kann. Um solches Verhalten zu vermeiden, müssen BGP-Implementierungen « Update Groups » unterstützen. Eine « Update Group » ist definiert als eine Menge von Nachbarn mit derselben ausgehenden Richtlinie : der lokale Speaker sendet BGP-Updates an die Gruppenmitglieder synchron.

Die Auswirkung solcher « Dispersion » wächst mit der Größe des Topologie-Fan-outs und kann auch bei hoher Konvergenz-Aktivität zunehmen. Einige Betreiber neigen dazu, « Route Flap Damping »-Funktionen zu aktivieren, die Hersteller zur Reduzierung der Steuerflächenbelastung durch schnell flappende Präfixe anbieten. Aufgrund der beschriebenen Fehlalarmprobleme in diesen Implementierungen, insbesondere bei solchen « Dispersion »-Ereignissen, wird jedoch empfohlen, diese Funktion in diesem Design nicht zu aktivieren. Hintergrund und Probleme von « Route Flap Damping » sowie mögliche Implementierungsänderungen sind in [RFC7196] gut beschrieben.

7.4. Umfang der Ausfallwirkung

Ein Netz gilt als konvergiert, wenn alle Geräte innerhalb des Ausfallwirkungsbereichs über das Ereignis informiert wurden und ihre RIBs neu berechnet und folglich ihre FIBs aktualisiert haben. Ein größerer Ausfallwirkungsbereich bedeutet typisch langsamere Konvergenz, da mehr Geräte benachrichtigt werden müssen, und führt zu einem weniger stabilen Netz. Dieser Abschnitt beschreibt BGP-Vorteile gegenüber Link-State-Routingprotokollen zur Reduzierung des Ausfallwirkungsbereichs in einer Clos-Topologie.

BGP verhält sich wie ein Distanzvektorprotokoll in dem Sinne, dass nur der beste Pfad aus Sicht des lokalen Routers an Nachbarn gesendet wird. Manche Ausfälle werden maskiert, wenn der lokale Knoten sofort einen Backup-Pfad findet und keine Updates weiter senden muss. Im schlimmsten Fall müssen alle Geräte in einer Rechenzentrums-Topologie entweder ein Präfix vollständig zurückziehen oder die ECMP-Gruppen in ihren FIBs aktualisieren. Viele Ausfälle haben jedoch nicht so weitreichende Auswirkungen. Es gibt zwei Hauptausfalltypen mit reduziertem Wirkungsbereich :

• Ausfall eines Links zwischen Tier-2- und Tier-1-Gerät : In diesem Fall aktualisiert ein Tier-2-Gerät die betroffenen ECMP-Gruppen und entfernt den ausgefallenen Link. Es ist nicht nötig, neue Informationen stromabwärts an Tier-3-Geräte zu senden, es sei denn, der Pfad wurde vom BGP-Prozess als bester gewählt; dann genügt ein « implicit withdraw », und die Weiterleitung sollte nicht beeinträchtigt werden. Das betroffene Tier-1-Gerät verliert den einzigen verfügbaren Pfad zu einem bestimmten Cluster und muss die zugehörigen Präfixe zurückziehen. Dieser Präfix-Withdraw-Prozess betrifft nur Tier-2-Geräte, die direkt mit dem betroffenen Tier-1-Gerät verbunden sind. Die Tier-2-Geräte, die BGP-UPDATE mit Präfix-Withdraw erhalten, müssen nur ihre ECMP-Gruppen aktualisieren. Tier-3-Geräte sind am Rekonvergenzprozess nicht beteiligt.

• Ausfall eines Tier-1-Geräts : In diesem Fall müssen alle Tier-2-Geräte, die direkt am ausgefallenen Knoten hängen, ihre ECMP-Gruppen für alle IP-Präfixe aus einem nicht-lokalen Cluster aktualisieren. Tier-3-Geräte sind erneut nicht am Rekonvergenzprozess beteiligt, können aber « implicit withdraws » wie oben beschrieben erhalten.

Selbst bei solchen Ausfällen, bei denen viele IP-Präfixe in der FIB neu programmiert werden müssen, teilen sich alle diese Präfixe eine einzige ECMP-Gruppe auf einem Tier-2-Gerät. Daher ist bei Implementierungen mit hierarchischer FIB nur eine Änderung in der FIB nötig. « Hierarchische FIB » bedeutet hier eine FIB-Struktur, in der Next-Hop-Weiterleitungsinformationen getrennt von der Präfix-Lookup-Tabelle gespeichert werden und letztere nur Zeiger auf die jeweiligen Weiterleitungsinformationen enthält. Siehe [BGP-PIC] zu FIB-Hierarchien und schneller Konvergenz.

Obwohl BGP in manchen Fällen den Ausfallumfang reduziert, ist eine weitere Verkleinerung der Fehlerdomäne durch Summarization im vorgeschlagenen Design nicht immer möglich, da diese Technik wie zuvor erwähnt Routing-Black-Holes erzeugen kann. Daher ist der schlimmste Ausfallwirkungsbereich auf der Steuerfläche das gesamte Netz, z. B. bei einem Linkausfall zwischen Tier-2- und Tier-3-Gerät. Die Anzahl betroffener Präfixe ist in diesem Fall viel geringer als bei einem Ausfall in den oberen Ebenen einer Clos-Topologie. Die Eigenschaft eines so großen Ausfallbereichs folgt nicht aus der Wahl von EBGP im Design, sondern aus der Nutzung der Clos-Topologie.

7.5. Routing-Mikroschleifen

Verliert ein stromabwärts gelegenes Gerät, z. B. Tier-2, alle Pfade für ein Präfix, zeigt es typischerweise die Standardroute zum stromaufwärtigen Gerät, hier Tier-1. Dadurch kann eine Situation entstehen, in der ein Tier-2-Switch ein Präfix verliert, ein Tier-1-Switch aber noch einen Pfad zum Tier-2 zeigt; das ergibt eine transiente Mikroschleife, da Tier-1-Pakete zum betroffenen Präfix weiter an Tier-2 sendet und Tier-2 sie über die Standardroute zurücksendet. Diese Mikroschleife dauert, bis das stromaufwärtige Gerät seine Weiterleitungstabellen vollständig aktualisiert hat.

Um die Auswirkung solcher Mikroschleifen zu minimieren, können Tier-2- und Tier-1-Switches mit statischen « discard »- oder « null »-Routen konfiguriert werden, die spezifischer als die Standardroute für während der Netzkonvergenz fehlende Präfixe sind. Für Tier-2-Switches sollte die Discard-Route eine Summary-Route sein, die alle Server-Subnetze der zugrunde liegenden Tier-3-Geräte abdeckt. Für Tier-1-Geräte sollte die Discard-Route eine Summary sein, die die für das gesamte Rechenzentrum zugewiesenen Server-IP-Subnetze abdeckt. Diese Discard-Routen haben nur während der Netzkonvergenz Vorrang, bis das Gerät ein spezifischeres Präfix über einen neuen Pfad lernt.