Zum Hauptinhalt springen

6.3. Routing Locator Reachability (Routing-Locator-Erreichbarkeit)

6.3. Routing Locator Reachability (Routing-Locator-Erreichbarkeit)

Mehrere Mechanismen wurden definiert, um die Erreichbarkeit von Routing Locators (RLOCs) zu bestimmen:

  1. Ein ETR kann die Locator-Status-Bits im LISP-Header gekapselter Datenpakete von einem ITR überprüfen. Wenn der ETR auch als ITR fungiert und es notwendig ist, Verkehr zurück zur ursprünglichen ITR-Site zu senden, können diese Statusinformationen bei der Auswahl von RLOCs helfen.

  2. Ein ITR kann ICMP Network Unreachable- oder Host Unreachable-Nachrichten für einen RLOC erhalten, den er verwendet. Dies deutet darauf hin, dass der RLOC möglicherweise ausgefallen ist. Beachten Sie, dass es nicht wünschenswert sein mag, ICMP-Nachrichten zu vertrauen, aber es ist auch nicht wünschenswert, sie vollständig zu ignorieren. Implementierungen werden ermutigt, bei der Behandlung dieser Situationen aktuelle Best Practices zu befolgen.

  3. Ein ITR, der am globalen Routing-System teilnimmt, kann basierend darauf, ob eine BGP Routing Information Base (RIB)-Route vorhanden ist, die mit der RLOC-IP-Adresse übereinstimmt, bestimmen, ob ein RLOC ausgefallen ist.

  4. Ein ITR kann eine ICMP Port Unreachable-Nachricht vom Zielhost erhalten. Dies kann auftreten, wenn ein ITR versucht, den Interworking-Mechanismus [RFC6832] zu verwenden, und LISP-gekapselte Daten an eine Site ohne LISP-Fähigkeit gesendet werden.

  5. Ein ITR kann eine Map-Reply von einem ETR als Antwort auf eine zuvor gesendete Map-Request erhalten. Die RLOC-Quelladresse der Map-Reply ist wahrscheinlich im Auf-Zustand, da der ETR in der Lage war, die Map-Reply an den ITR zu senden.

  6. Wenn ein ETR ein gekapseltes Paket von einem ITR empfängt, ist der Quell-RLOC im äußeren Header des Pakets wahrscheinlich im Auf-Zustand.

  7. ITR/ETR-Paare können die in diesem Abschnitt beschriebenen Locator-Erreichbarkeitsalgorithmen verwenden, nämlich Echo-Noncing oder RLOC-Probing.

Bei der Bestimmung der Locator-Auf-/Ab-Erreichbarkeit durch Überprüfung der Locator-Status-Bits in LISP-gekapselten Datenpaketen erhält ein ETR den aktuellsten Status über die Erreichbarkeit aller ETRs an dieser Site vom kapselnden ITR. CE-basierte ITRs an der Quell-Site können die gegenseitige Erreichbarkeit mithilfe des Site-IGP wie folgt bestimmen:

  • Normalerweise kündigt jeder ITR eine Standardroute im Site-IGP an.

  • Wenn ein ITR ausfällt oder sein Uplink zum PE ausfällt, läuft seine Standardroute ab oder wird zurückgezogen.

Daher kann jeder ITR beobachten, ob andere ITRs noch Standardrouten ankündigen, und die Locator-Status-Bits entsprechend setzen.

RLOCs, die in einer Map-Reply aufgelistet sind, werden von 0 bis n-1 nummeriert. Die Locator-Status-Bits in einem LISP-gekapselten Paket werden vom niedrigstwertigen Bit an von 0 bis n-1 nummeriert. Wenn beispielsweise der RLOC an der dritten Position in der Map-Reply ausgefallen ist (Ordnungszahl 2), löschen alle ITRs an der Site das dritte niedrigstwertige Bit (xxxx x0xx) im Locator-Status-Bits-Feld, das sie für gekapselte Pakete setzen.

Ein ETR überprüft bei der Entkapselung das Locator-Status-Bits-Feld auf Änderungen. Wenn ein Bit von 1 auf 0 wechselt und der ETR auch als ITR fungiert, hört er auf, Pakete zum als "down" markierten RLOC zu kapseln. Er verwendet den RLOC nur wieder, wenn das entsprechende Locator-Status-Bit auf 1 zurückkehrt. Die Locator-Status-Bits sind mit dem Locator-Set jedes EID-Präfix verbunden. Wenn daher ein Locator nicht erreichbar ist, wird das Locator-Status-Bit, das der Position dieses Locators in der Liste der letzten zurückgegebenen Map-Reply entspricht, für dieses EID-Präfix auf Null gesetzt.

Wenn ITRs an einer Site nicht auf CE-Routern bereitgestellt werden, kann das IGP weiterhin zur Bestimmung der Locator-Erreichbarkeit verwendet werden, vorausgesetzt, die Lokatoren werden in das IGP eingefügt. Dies geschieht normalerweise durch Konfiguration von /32-Adressen auf Loopback-Schnittstellen.

Wenn ein ITR ICMP Network Unreachable- oder Host Unreachable-Nachrichten als Mittel zur Bestimmung von Unerreichbarkeit verwendet, hört er auf, Lokatoren zu verwenden, die in der Locator-Liste der Map-Reply beschrieben sind. Diese Methode ist jedoch nicht zuverlässig, da viele Netzbetreiber die Generierung von ICMP Destination Unreachable deaktiviert haben.

Wenn ein ITR tatsächlich eine ICMP Network Unreachable- oder Host Unreachable-Nachricht erhält, kann er selbst eine ICMP Destination Unreachable-Nachricht für den Host generieren, der das Datenpaket initiiert hat, das vom ITR gekapselt wurde.

Darüber hinaus kann ein BGP-fähiger ITR einseitig die RIB überprüfen, um zu sehen, ob Locator-Adressen im Locator-Set eines Zuordnungseintrags mit einem Präfix übereinstimmen. Wenn keiner gefunden wird und BGP in der Default-Free Zone (DFZ) läuft, kann er entscheiden, diesen Locator nicht zu verwenden, auch wenn die Locator-Status-Bits anzeigen, dass der Locator "up" ist. Zu diesem Zeitpunkt ist der Pfad vom ITR zum ETR, dem der Locator zugewiesen ist, nicht verfügbar. Siehe [LOC-ID-ARCH] für weitere Details.

Optional kann ein ITR eine Map-Request an einen Locator senden, und wenn eine Map-Reply zurückgegeben wird, hat er festgestellt, dass der Locator erreichbar ist. Offensichtlich erhöht das Senden solcher Probes die Anzahl der Kontrollnachrichten, die Tunnel-Router für aktive Flows erzeugen, daher wird angenommen, dass angekündigte Lokatoren erreichbar sind.

Diese Annahme schafft tatsächlich eine Abhängigkeit: Locator-Unerreichbarkeit wird durch den Empfang von ICMP Host Unreachable-Nachrichten erkannt. Wenn festgestellt wird, dass ein Locator nicht erreichbar ist, wird er nicht mehr für aktiven Verkehr verwendet, was dem Auflisten dieses Locators mit Priority 255 in einer Map-Reply entspricht.

Ein ITR kann die Erreichbarkeit nicht erreichbarer Lokatoren testen, indem er periodisch Requests sendet. Sowohl Requests als auch Replies müssen ratenbegrenzt sein. Locator-Erreichbarkeitstests werden niemals mit Datenpaketen durchgeführt, da dies das Risiko von Paketverlusten für End-zu-End-Sitzungen erhöhen würde.

Wenn ein ETR ein Paket entkapselt, weiß er, dass vom kapselnden ITR zu ihm selbst Erreichbarkeit besteht, da das Paket über diesen Pfad angekommen ist. In den meisten Fällen kann der ETR auch den ITR erreichen, aber dies kann nicht angenommen werden, da der Pfad asymmetrisch sein kann. Wenn unidirektionaler Verkehr vom ITR zum ETR existiert, sollte der ITR das Fehlen von Rückverkehr nicht als Indikator für ETR-Unerreichbarkeit betrachten. Stattdessen müssen andere Mechanismen zur Bestimmung der Erreichbarkeit verwendet werden.