In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Dieses Dokument beantwortet die am häufigsten gestellten Fragen zum Multiprotocol Label Switching (MPLS) von einem Anfänger.
MPLS ist eine Paketweiterleitungstechnologie, die Labels verwendet, um Entscheidungen über die Datenweiterleitung zu treffen. Mit MPLS wird die Layer-3-Header-Analyse nur einmal durchgeführt (wenn das Paket in die MPLS-Domäne eingeht). Die Label-Überprüfung ermöglicht die anschließende Paketweiterleitung. MPLS bietet folgende nützliche Anwendungen:
Virtual Private Networking (VPN)
Traffic Engineering (TE)
Quality of Service (QoS)
Jeder Transport über MPLS (AToM)
Darüber hinaus wird der Weiterleitungs-Overhead auf den Core-Routern verringert. MPLS-Technologien können für alle Protokolle auf der Netzwerkschicht verwendet werden.
Ein Label ist eine kurze, vier Byte lange, lokal signifikante Kennung mit fester Länge, die zur Identifizierung einer Forwarding Equivalence Class (FEC) verwendet wird. Das Label, das auf einem bestimmten Paket platziert wird, repräsentiert die FEC, der dieses Paket zugewiesen ist.
Label - Label-Wert (unstrukturiert), 20 Bit
Exp - Experimentelle Verwendung, 3 Bit; wird derzeit als CoS-Feld (Class of Service) verwendet
S - Unterseite des Stapels, 1 Bit
TTL = Time to Live (Lebensdauer, 8 Bit)
Das Label wird zwischen dem Header der Sicherungsschicht (Layer 2) und dem Header der Netzwerkschicht (Layer 3) eingefügt. Der obere Teil des Etikettenstapels wird zuerst im Paket und der untere Teil als letzter angezeigt. Das Paket der Netzwerkschicht folgt sofort dem letzten Label im Label-Stack.
Eine FEC ist eine Gruppe von IP-Paketen, die auf die gleiche Weise, über den gleichen Pfad und mit der gleichen Weiterleitungsbehandlung weitergeleitet werden. Ein FEC kann einem Ziel-IP-Subnetz entsprechen, aber auch jeder Datenverkehrsklasse, die der Edge-LSR als signifikant erachtet. So könnte beispielsweise der gesamte Datenverkehr mit einem bestimmten Wert der IP-Rangfolge einen FEC darstellen.
Upstream und Downstream sind relative Begriffe in der MPLS-Welt. Sie beziehen sich immer auf ein Präfix (besser gesagt, einen FEC). Diese Beispiele erläutern dies näher.
Für FEC 10.1.1.0/24 ist R1 der Downstream-LSR zu R2.
Für FEC 10.1.1.0/24 ist R2 der Upstream-LSR zu R1.
Bei FEC 10.1.1.0/24 ist R1 der Downstream-LSR zu R2 und R2 der Downstream-LSR zu R3.
Für FEC 10.1.1.0/24 ist R1 der Downstream-LSR zu R2. Für FEC 10.2.2.0/24 ist R2 der Downstream-LSR zu R1.
Die Daten werden von Upstream zu Downstream übertragen, um das Netzwerk zu erreichen (Präfix).
In der R4-Routing-Tabelle werden R1, R2 und R3 als Next-Hops festgelegt, um 10.1.1.0/24 zu erreichen.
Nein, Daten werden von Upstream zu Downstream übertragen.
Berücksichtigen Sie R2 und R3 in dieser Topologie. R2 vertreibt ein Label L für FEC F an R3. R3 verwendet das Label L, wenn er Daten an FEC-F weiterleitet (da R2 der nachgeschaltete LSR für FEC-F ist). In diesem Szenario gilt Folgendes:
L ist das eingehende Label für F auf R2.
L ist das Ausgangskennzeichen für FEC-F auf R3.
L ist die lokale Bindung für FEC F auf R2.
L ist die Remote-Bindung für FEC-F auf R3.
Ja, wenn die IP-Adresse auf der Schnittstelle aktiviert ist. Native Pakete werden wie gewohnt empfangen/übertragen. IP ist nur ein weiteres Protokoll. MPLS-Pakete haben eine andere Layer-2-Kodierung. Der empfangende LSR erkennt das MPLS-Paket anhand der Layer-2-Codierung.
Nein. Pakete werden niemals über eine Schnittstelle übertragen, die für dieses Protokoll nicht aktiviert ist. MPLS verfügt über einen bestimmten Ethertype-Code (genau wie IP, IPX und Appletalk über eindeutige Ethertypes). Empfängt ein Cisco Router ein Paket mit einem Ethertype, der auf der Schnittstelle nicht aktiviert ist, verwirft er das Paket. Wenn beispielsweise ein Router ein Appletalk-Paket über eine Schnittstelle empfängt, für die Appletalk nicht aktiviert ist, verwirft er das Paket. Wenn ein MPLS-Paket an einer Schnittstelle empfangen wird, für die MPLS nicht aktiviert ist, wird das Paket ebenfalls verworfen.
Cisco Serien 2691, 3640, 3660, 3725, 3745, 6400-NRP-1, 6400-NRP-2SV, 6400-NSP, Catalyst 5000 mit Route Switch Module (RSM) 7200, 7301, 7400, 7500, Catalyst Serie 6500/Cisco 7600 mit WS-SUP720-3B und WS-SUP720-3BXL, Gigabit Switch Router (GSR), Routingprozessormodul (RPM) Universal Broadband Router (UBR) 7200, AS5350 und IGX8400-URM unterstützen alle MPLS.
Diese Plattformen unterstützen das Cisco Tag Distribution Protocol (TDP) als Label Distribution Protocol.
Informationen zu Label Distribution Protocol (LDP), Resource Reservation Protocol (RSVP) und Border Gateway Protocol (BGP) finden Sie im Software Advisor-Tool (nur registrierte Kunden). Software Advisor bietet eine vollständige Liste der von den verschiedenen Cisco IOS-Versionen und -Plattformen unterstützten Funktionssätze.
Ein MPLS-LSP-Tunnel hat ein Label (vier Bytes) oder zwei Labels (z. B. bei Verwendung von Link Protection Fast Reroute) für den Overhead. Im Gegensatz zu einem GRE-Tunnel ändert MPLS den IP-Header nicht. Stattdessen wird der Label-Stack dem Paket zugewiesen, das den Tunnelpfad nutzt.
Das Label unmittelbar nach dem Layer-2-Header ist das obere Label, und das Label mit dem S-Bit auf 1 ist das untere Label. Keine Anwendung benötigt LSR zum Lesen/Identifizieren der mittleren Labels. Ein Label ist jedoch ein mittleres Label, wenn es sich nicht oben im Stack befindet und das S-Bit auf 0 festgelegt ist.
Diese Werte finden Sie auch in RFC3032 - MPLS Label Stack Encoding.
Theoretisch liegt der Bereich zwischen 0 und (220-1). Labelwerte 0-15 sind reserviert, und die Werte 4-15 sind für die zukünftige Verwendung reserviert. Die Werte 0-3 werden wie folgt definiert:
Ein Wert von 0 steht für das IPv4 Explicit NULL Label. Dieses Label gibt an, dass der Label-Stack geöffnet werden muss und die Paketweiterleitung auf dem IPv4-Header basieren muss. Dies hilft, Exp-Bits bis zum Egress-Router sicher zu halten. Wird für MPLS-basiertes QoS verwendet
Der Wert 1 steht für die Router-Warnmeldungsbezeichnung. Wenn ein empfangenes Paket diesen Label-Wert oben im Label-Stack enthält, wird es zur Verarbeitung an ein lokales Softwaremodul übermittelt. Die tatsächliche Paketweiterleitung wird durch das darunter im Stack befindliche Label bestimmt. Wenn das Paket jedoch weiter geleitet wird, sollte das Router-Warnmeldungsfeld vor der Weiterleitung zurück auf den Label-Stack geschoben werden. Die Verwendung dieses Labels entspricht der Verwendung der Router Alert Option in IP-Paketen (z. B. Ping mit Record Route Option)
Der Wert 2 stellt das IPv6 Explicit NULL Label dar. Sie gibt an, dass der Label-Stack geöffnet werden muss und die Paketweiterleitung auf dem IPv6-Header basieren muss.
Ein Wert von 3 steht für die Implicit NULL Label (Implizite NULL). Dies ist ein Label, das ein LSR zuweisen und verteilen kann. Es erscheint jedoch niemals tatsächlich in der Kapselung. Es zeigt an, dass der LSR das oberste Label aus dem Stack entfernt und den Rest des Pakets (gekennzeichnet oder unmarkiert) über die Ausgangsschnittstelle weiterleitet (gemäß dem Eintrag in Lfib). Obwohl dieser Wert in der Kapselung möglicherweise nie vorkommt, muss er im Label Distribution Protocol angegeben werden, sodass ein Wert reserviert wird
LDP verwendet den TCP-Port 646 und TDP den TCP-Port 711. Diese Ports werden an der Router-Schnittstelle nur geöffnet, wenn mpls ip auf der Schnittstelle konfiguriert ist. Die Verwendung von TCP als Transportprotokoll führt zu einer zuverlässigen Bereitstellung von LDP/TDP-Informationen mit zuverlässiger Flusssteuerung und Engpassbehandlungsmechanismen.
Die mit der MPLS-Domäne verbundene Schnittstelle muss eines der optischen Dienstmodule (OSM) (z. B. jedes Modul, das den PXF-Komplex (Parallel Express Forwarding) verwendet) oder eine Schnittstelle im FlexWAN-Modul verwenden. Dieselbe Einschränkung gilt für das MPLS-Layer-3-VPN. Das heißt, der IP-Frame muss auf einer WAN-Schnittstelle eingegeben werden, die entweder ein OSM oder eine Schnittstelle in einem FlexWAN-Modul ist. Diese Einschränkungen gelten nicht für einen Supervisor 720.
Viele MPLS-Konfigurationsdokumente befinden sich unter Implementierung und Konfiguration: MPLS.
Ein Lastenausgleich für MPLS-Pakete kann mit den MPLS-Label-Informationen und/oder der Quell- und Zieladresse des essenziellen IP-Headers erfolgen.
Wenn Sie eine Verbindung mit einem Remote-Standort über MPLS herstellen, handelt es sich um eine Layer-3-Verbindung, und der 802.1Q-Trunk ist ein Layer-2-Protokoll, sodass Sie über eine MPLS-Verbindung keinen 802.1Q-Trunk haben können. Sie benötigen eine Metro Ethernet-Verbindung oder 802.1Q-Tunneling, um Ihr VLAN zu erweitern. Dies wird vom ISP bereitgestellt. In der MPLS-Cloud kommuniziert der ISP über VRF.
Weitere Informationen finden Sie unter Configuring IEEE 802.1Q Tunneling.
Ja, es ist keine zusätzliche Konfiguration erforderlich.
Ja, die DHCP-Anfrage wird innerhalb der VRF-Instanz über das MPLS-VPN-Netzwerk weitergeleitet, und der Ausgangs-Provider-Edge sendet sie in derselben VRF-Instanz an den DHCP-Server.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
28-Sep-2001 |
Erstveröffentlichung |