RFC 4379 - 2. Motivation

2. Motivation

Wenn ein LSP keinen Benutzerverkehr mehr zustellt, kann der Fehler nicht immer von der MPLS-Kontrollebene erkannt werden. Es besteht Bedarf an einem Werkzeug, mit dem Anwender solche Verkehrs-"schwarzen Löcher" oder Fehlleitungen innerhalb eines angemessenen Zeitraums erkennen können, sowie an einem Mechanismus zur Fehlerisolierung.

In diesem Dokument beschreiben wir einen Mechanismus, der diese Ziele erreicht. Dieser Mechanismus ist dem ping/traceroute-Paradigma nachempfunden: ping (ICMP echo request [ICMP]) dient der Konnektivitätsprüfung, und traceroute dient der hopweisen Fehlerlokalisierung sowie der Pfadverfolgung. Dieses Dokument spezifiziert einen "ping"-Modus und einen "traceroute"-Modus zum Testen von MPLS LSPs.

Die Grundidee ist zu verifizieren, dass Pakete, die zu einer bestimmten Forwarding Equivalence Class (FEC) gehören, ihren MPLS-Pfad tatsächlich auf einem Label Switching Router (LSR) beenden, der ein Egress für diese FEC ist. Dieses Dokument schlägt vor, diesen Test durchzuführen, indem ein Paket (ein sogenannter "MPLS echo request") entlang desselben Datenpfads gesendet wird wie andere Pakete, die zu dieser FEC gehören. Ein MPLS echo request trägt außerdem Informationen über die FEC, deren MPLS-Pfad verifiziert wird. Dieser echo request wird genau wie jedes andere Paket dieser FEC weitergeleitet. Im "ping"-Modus (grundlegende Konnektivitätsprüfung) sollte das Paket das Ende des Pfads erreichen; dort wird es an die Kontrollebene des Egress-LSR gesendet, der anschließend prüft, ob er tatsächlich ein Egress für die FEC ist. Im "traceroute"-Modus (Fehlerisolierung) wird das Paket an die Kontrollebene jedes Transit-LSR gesendet, der verschiedene Prüfungen durchführt, um festzustellen, dass er tatsächlich ein Transit-LSR für diesen Pfad ist; dieser LSR liefert zudem weitere Informationen zurück, die helfen, die Kontrollebene gegen die Datenebene zu prüfen, d. h. zu verifizieren, dass die Weiterleitung mit dem übereinstimmt, was die Routingprotokolle als Pfad bestimmt haben.

Eine Möglichkeit, diese Werkzeuge zu nutzen, besteht darin, eine FEC periodisch zu pingen, um die Konnektivität sicherzustellen. Schlägt das Ping fehl, kann man anschließend ein Traceroute starten, um festzustellen, wo der Fehler liegt. Man kann FECs auch periodisch tracen, um zu verifizieren, dass die Weiterleitung mit der Kontrollebene übereinstimmt; dies belastet die Transit-LSRs jedoch stärker und sollte daher mit Vorsicht verwendet werden.

2.1. Verwendung des Adressbereichs 127/8 (Use of Address Range 127/8)

Wie oben beschrieben, ist LSP ping als Diagnosewerkzeug gedacht. Es soll Anbietern eines MPLS-basierten Dienstes ermöglichen, Netzfehler zu isolieren. Insbesondere muss LSP ping Situationen diagnostizieren, in denen Kontroll- und Datenebene nicht synchron sind. Dies erreicht es, indem ein MPLS echo request-Paket ausschließlich anhand seines Label-Stacks geroutet wird. Das heißt, die IP-Zieladresse wird nie für eine Weiterleitungsentscheidung verwendet. Tatsächlich kennt der Absender eines MPLS echo request-Pakets die Adresse des Routers am Ende des LSP möglicherweise nicht im Voraus.

Anbieter MPLS-basierter Dienste benötigen außerdem die Fähigkeit, alle möglichen Pfade zu verfolgen, die ein LSP nehmen kann. Da die meisten MPLS-Dienste auf IP-Unicast-Weiterleitung basieren, unterliegen diese Pfade dem Load Sharing über Equal-Cost Multi-Path (ECMP).

Daraus ergeben sich die folgenden Anforderungen:

1. Obwohl das betreffende LSP in unbekannter Weise defekt sein kann, muss die Wahrscheinlichkeit, dass ein Diagnosepaket an einen Nutzer eines MPLS-Dienstes zugestellt wird, auf ein absolutes Minimum begrenzt werden (MUST).

2. Wenn ein LSP so defekt ist, dass er vorzeitig endet, darf das Diagnosepaket NICHT per IP weitergeleitet werden (MUST NOT).

3. Ein Mittel, die Diagnosepakete so zu variieren, dass sie alle ECMP-Pfade durchlaufen, ist daher erforderlich (REQUIRED).

Offensichtlich erfüllt die Verwendung allgemeiner Unicast-Adressen keine der beiden ersten Anforderungen. Es wurden eine Reihe anderer Adressoptionen erwogen, darunter ein Teil des privaten Adressraums (nach Wahl des Netzbetreibers) und die neu festgelegten IPv4-Link-Local-Adressen. Die Verwendung des privaten Adressraums wurde als wirkungslos erachtet, da der führende MPLS-basierte Dienst ein IPv4 Virtual Private Network (VPN) ist. VPNs verwenden häufig private Adressen.

Die IPv4-Link-Local-Adressen sind attraktiver, weil der Bereich, über den sie weitergeleitet werden können, begrenzt ist. Wenn man jedoch eine Adresse aus diesem Bereich verwenden würde, wäre es weiterhin möglich, dass der erste Empfänger eines Diagnosepakets, das einem defekten LSP "entkommen" ist, diese Adresse auf der Schnittstelle zugewiesen hat, über die es ankam, und das Paket somit fälschlich entgegennehmen könnte. Darüber hinaus wurde der IPv4-Link-Local-Adressbereich erst kürzlich zugewiesen. Viele eingesetzte Router würden ein Paket mit einer Adresse aus diesem Bereich in Richtung der Default-Route weiterleiten.

Der Bereich 127/8 für IPv4 und derselbe, als IPv4-gemappte IPv6-Adressen in IPv6 eingebettete Bereich wurden aus einer Reihe von Gründen gewählt.

RFC 1122 weist 127/8 als "Internal host loopback address" (interne Host-Loopback-Adresse) zu und stellt fest: "Addresses of this form MUST NOT appear outside a host." (Adressen dieser Form dürfen außerhalb eines Hosts nicht erscheinen (MUST NOT).) Somit besteht das Standardverhalten von Hosts darin, solche Pakete zu verwerfen. Dies trägt dazu bei sicherzustellen, dass ein Diagnosepaket, das fälschlich an einen Host geleitet wird, stillschweigend verworfen wird.

RFC 1812 [RFC1812] stellt fest:

Ein Router SHOULD NOT Pakete weiterleiten, deren Zieladresse im Netz 127 liegt, außer über eine Loopback-Schnittstelle. Ein Router MAY über einen Schalter verfügen, der es dem Netzmanagement erlaubt, diese Prüfungen zu deaktivieren. Wird ein solcher Schalter bereitgestellt, MUST er standardmäßig die Prüfungen durchführen.

Dies trägt dazu bei sicherzustellen, dass Diagnosepakete niemals per IP weitergeleitet werden.

Der Adressbereich 127/8 bietet 16M Adressen und erlaubt damit große Flexibilität bei der Variation von Adressen, um ECMP-Pfade zu durchlaufen. Schließlich bietet 127/8 als Implementierungsoptimierung ein einfaches Mittel, um mögliche LSP-Pakete zu identifizieren.