Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

DiffServ-orientierte Traffic Engineering-Konfiguration

DiffServ-orientiertes Traffic Engineering – Einführung

DiffServ-orientiertes Traffic-Engineering (differenzierte Services) bietet die Möglichkeit, eine bestimmte Serviceebene über ein bestimmtes Netzwerk MPLS garantieren. Die Router, die DiffServ-orientiertes Traffic-Engineering bereitstellen, sind Teil einer differenzierten Service-Netzwerk-Domäne. Alle Router, die in einer differenzierten Servicedomäne aktiv sind, müssen über ein DiffServ-fähiges Traffic Engineering verfügen.

Um sicherzustellen, dass die angegebene Serviceebene angegeben ist, muss sichergestellt werden, dass nicht mehr als die angegebene Datenverkehrsmenge über die differenzierte Dienstdomäne gesendet wird. Sie können dieses Ziel erreichen, indem Sie einen Policer zur Police konfigurieren oder das Verkehrsvolumen, das durch die differenzierte Dienstdomäne geht, begrenzen. Weitere Informationen zur Konfiguration von Policern für Label-Switched Paths (LSPs) finden Sie unter Konfigurieren von Policern für LSPs.

Diese Funktion kann zur Verbesserung der Qualität von Internetdiensten wie Voice over IP (VoIP) beitragen. Darüber hinaus ist es möglich, eine ATM-Verbindung (Asynchronous Transfer Mode) besser über ein MPLS zu emulieren.

DiffServ-orientierte Traffic Engineering-Terminologie

Bandbreitenmodell

Das Bandbreitenmodell ermittelt die Werte der verfügbaren Bandbreite, die von den Interior Gateway Protocols (IGPs) angeboten wird.

Cac

Call Admission Control (CAC)-Prüfungen stellen sicher, dass auf dem Pfad ausreichende Bandbreite verfügbar ist, bevor der LSP eingerichtet wird. Wenn die Bandbreite nicht ausreichend ist, wird der LSP nicht festgelegt und ein Fehler wird gemeldet.

Klassentyp

Eine Ansammlung von Datenverkehrsflüssen, die entsprechend in einer differenzierten Servicedomäne behandelt werden. Ein Klassentyp ordnet einer Warteschlange zu und ist ähnlich wie eine Class-of-Service-Weiterleitungsklasse (CoS). Sie ist auch als Datenverkehrsklasse bekannt.

Differenzierte Services

Differenzierte Dienste ermöglichen die unterschiedliche Behandlung von Datenverkehr basierend auf den EXP-Bits in der MPLS Header. Der Datenverkehr muss entsprechend markiert und CoS konfiguriert werden.

Domain mit differenzierten Services

Die Router in einem Netzwerk mit differenzierten Services.

DiffServ-orientiertes Traffic-Engineering

Eine Art constraint-basiertes Routing. Dies kann unterschiedliche Bandbreiteneinschränkungen für verschiedene Datenverkehrsklassen durchsetzen. Wenn ein LSP eingerichtet wird, kann er auch CAC für jede Traffic Engineering-Klasse bieten.

Multi-class-LSP

Ein Multi-Class-LSP funktioniert wie ein Standard-LSP, ermöglicht ihnen aber auch das Reservieren der Bandbreite bei mehreren Klassentypen. Die EXP-Bits der MPLS werden zur Unterscheidung zwischen Klassentypen verwendet.

Mam

Das Modell mit Bandbreiteneinschränkungen für die maximale Zuweisung unterteilt die verfügbare Bandbreite zwischen den verschiedenen Klassen. Die gemeinsame Nutzung der Bandbreite zwischen den Klassentypen ist nicht zulässig.

Rdm

Das Bandbreiteneinschränkungsmodell für russische Dolls nutzt die Bandbreite effizient, da die Klassentypen die Bandbreite gemeinsam nutzen können.

Traffic Engineering-Klasse

Ein gekoppelter Klassentyp und eine gekoppelte Priorität.

Traffic Engineering Class-Übersicht

Eine Übersicht zwischen den Klassentypen, -prioritäten und den Traffic-Engineering-Kursen. Die Zuordnung der Traffic Engineering-Klasse muss in der Domain für differenzierte Services konsistent sein.

DiffServ-orientierte Traffic Engineering-Funktionen

DiffServ-orientiertes Traffic-Engineering bietet die folgenden Funktionen:

  • Traffic-Engineering auf einer Ebene pro Klasse statt auf einer aggregierten Ebene

  • Unterschiedliche Bandbreiteneinschränkungen für verschiedene Klassentypen (Datenverkehrsklassen)

  • Unterschiedliche Queuing-Verhaltensweisen pro Klasse, sodass der Router Datenverkehr auf der Basis des Klassentyps weitergeleitet werden kann

Im Vergleich dazu wird das Standard-Traffic-Engineering nicht CoS, und es führt seine Arbeit auf aggregierter Basis über alle differenzierten Dienstklassen aus.

DiffServ-orientiertes Traffic-Engineering bietet die folgenden Vorteile:

  • Traffic-Engineering kann auf einer bestimmten Klassenart anstatt auf der aggregierten Ebene ausgeführt werden.

  • Bandbreiteneinschränkungen können für jeden bestimmten Klassentyp durchgesetzt werden.

  • Er weitergeleitet Datenverkehr auf der Grundlage der EXP-Bits.

Dadurch können Service und Bandbreite innerhalb eines Netzwerks MPLS garantiert werden. Mit DiffServ-orientiertem Traffic Engineering können Sie, unter anderem, ATM-Circuit-Emulation, VoIP und einen garantierten Bandbreitendienst bereitstellen.

Im Folgenden wird beschrieben, wie IGP, Constrained Shortest Path First (CSPF) und RSVP am DiffServ-orientiertem Traffic Engineering beteiligt sind:

  • Der IGP anderen Mitgliedern der differenzierten Servicedomäne die nicht verfügbare Bandbreite für jede Traffic Engineering-Klasse anbieten. Die Traffic-Engineering-Datenbank speichert diese Informationen.

  • Eine CSPF-Berechnung wird unter Berücksichtigung der Bandbreiteneinschränkungen für jeden Klassentyp durchgeführt. Wenn alle Beschränkungen erfüllt sind, gilt die CSPF-Berechnung als erfolgreich.

  • Wenn RSVP einen LSP anspricht, fordert er Bandbreite für bestimmte Klassentypen an.

Übersicht über DiffServ-orientierte Traffic Engineered-LSPs

Ein DiffServ- awarer Traffic Engineered LSP ist ein LSP, der mit einer Bandbreitenreservierung für einen bestimmten Klassentyp konfiguriert ist. Dieser LSP kann Datenverkehr für einen einzelnen Klassentyp tragen. Auf den Paketen wird der Klassentyp durch die EXP-Bits (auch als Class-of-Service-Bits bekannt) und das mit den EXP-Bits verbundene Per-Hop-Verhalten (PHB) festgelegt. Die Zuordnung zwischen EXP-Bits und PHB ist statisch, anstelle von Signalen in RSVP.

Der Klassentyp muss in der gesamten Domain für differenzierte Dienste konsistent konfiguriert sein, d. h. die Konfiguration des Klassentyps muss vom Router zum Router im Netzwerk konsistent sein. Sie können einen Klassentyp eindeutig einer Warteschlange zuordnen. Auf jedem Knotenrouter wird die Warteschlangenkonfiguration nach Dienstklassen für eine Schnittstelle auf die verfügbare Bandbreite für einen bestimmten Klassentyp in diesem Link übertragen.

Weitere Informationen zu LSPs und DiffServ-orientiertem Traffic-Engineering finden Sie unter:

  • Informationen zu Weiterleitungsklassen Class-of-Servicefinden Sie im Benutzerhandbuch Junos OS Class of Service für Routinggeräte.

  • Informationen zu EXP-Bits finden Sie unter MPLS Label Allocation.

  • Weitere Informationen zu differenzierten Services finden Sie unter RFC 3270, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services.

  • Informationen dazu, wie IGPs und RSVP zur Unterstützung von Differentiated Services-Aware MPLS-Traffic Engineering geändert wurden, finden Sie in RFC 4124, Protocol Extensions for Support of Differentiated-Service-Aware MPLS Traffic Engineering.

DiffServ-orientierte Traffic Engineered-LSPs-Betrieb

Bei der Konfiguration eines DiffServ-orientiertem Traffic Engineered-LSP geben Sie den Klassentyp und die damit verbundene Bandbreite an. Das Folgende tritt auf, wenn ein LSP mit Bandbreitenreservierung von einem bestimmten Klassentyp eingerichtet wird:

  1. Die IGPs geben an, wie viel ununeingeschränkte Bandbreite für die Traffic Engineering-Klassen zur Verfügung steht.

  2. Bei der Berechnung des Pfads für einen LSP wird CSPF verwendet, um sicherzustellen, dass die Bandbreiteneinschränkungen für den Vom LSP auf der angegebenen Prioritätsebene durchgeführten Klassentyp erfüllt werden.

    CSPF überprüft auch, ob das Bandbreitenmodell konsistent auf jedem Router konfiguriert wird, der am LSP teiliert. Wenn das Bandbreitenmodell inkonsistent ist, berechnet CSPF den Pfad nicht (außer für LSPs vom Klassentyp CT0).

  3. Sobald ein Pfad gefunden wurde, signalisiert RSVP den LSP mithilfe des Classtype-Objekts in der Pfadnachricht. An jedem Knoten im Pfad wird die verfügbare Bandbreite der Klassentypen bei der Einrichtung des Pfads angepasst.

Ein LSP, der die Bandbreite einer bestimmten Klasse erfordert (außer Klassentyp CT0), kann nicht über Router eingerichtet werden, die das Classtype-Objekt nicht verstehen. Die Verhinderung der Verwendung von Routern, die das Classtype-Objekt nicht verstehen, kann die Konsistenz in der Domäne differenzierter Dienste sicherstellen, indem verhindert wird, dass der LSP einen Router verwendet, der differenzierte Dienste nicht unterstützt.

Standardmäßig werden die LSPs mit der Einrichtungspriorität 7 und der Priorität 0 signalisiert. Ein mit diesen Werten konfigurierter LSP kann einen anderen LSP bei der Einrichtung nicht vorkonfiguriert und kann nicht vorgefertigt werden.

Es ist möglich, dass sowohl LSPs für DiffServ-orientiertes Traffic Engineering als auch regelmäßige LSPs gleichzeitig auf den gleichen physischen Schnittstellen konfiguriert sind. Für diese Art heterogener Umgebung tragen regelmäßiger LSPs standardmäßig Best-Effort-Datenverkehr. Der in den regelmäßigen LSPs durchgeführte Datenverkehr muss über die richtigen EXP-Einstellungen verfügen (entweder durch Neueinstellungen in den EXP-Einstellungen oder durch die Annahme, dass der Datenverkehr mit den korrekten EXP-Einstellungen des Upstream-Routers eintraf).

Konfigurieren von Routern für DiffServ-orientiertes Traffic Engineering

Um DiffServ-orientiertes Traffic Engineering zu konfigurieren, müssen Sie die Anweisung diffserv-te beinhalten:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Sie müssen die Anweisung in die Konfiguration aller Router, die in der diffserv-te Domäne differenzierter Dienste (Differentiated Services) teilnehmen, enthalten. Sie müssen jedoch keine Traffic Engineering Class-Matrix konfigurieren (einschließlich der Anweisung te-class-matrix auf der oder der [edit protocols mpls diffserv-te][edit logical-systems logical-system-name protocols mpls diffserv-te] Hierarchieebene).

Anmerkung:

Um zu verhindern, dass bei der Migration zu Diffserv-orientiertem Traffic Engineering die Möglichkeit einer fehlerhaften Konfiguration besteht, kann ein Fehler bei der Richtlinienkontrolle ausgelöst werden, wenn ein Konflikt zwischen den alten LSPs und der neu konfigurierten TE-Klassenmatrix vorhanden ist.

Ein alter Knoten fordert möglicherweise einen LSP mit Setup- und Hold-Prioritäten an, so dass die Kombination der CT0-Klasse und der Priorität nicht mit der konfigurierten TE-Class-Matrix übereinstimmen. Alle LSPs auf dem Router, die vor der Konfiguration von diffserv-orientiertem Traffic-Engineering konfiguriert sind, gelten als class ct0.

Der Fehler wird in den RSVP-Tracing-Protokollen als Session preempted Fehler angezeigt. Für den Router, von dem der Fehler stammt, kann der Fehler wie folgt angezeigt werden:

Für den Router, der den Fehler empfängt, kann der Fehler wie folgt angezeigt werden:

Um das DiffServ-orientierte Traffic Engineering zu konfigurieren, führen Sie die Verfahren in den folgenden Abschnitten aus:

Konfigurieren des Bandbreitenmodells

Sie müssen ein Bandbreitenmodell auf allen Routern konfigurieren, die in der Domain für differenzierte Dienste (Differentiated Services) teilnehmen. Die verfügbaren Bandbreitenmodelle sind MAM, erweiterte MAM und RDM:

  • Modell mit Bandbreiteneinschränkungen für maximale Zuordnung (MAM) – Definiert in RFC 4125, Modell mit maximaler Zuweisung Bandbreiteneinschränkungen für Diffserv-orientierteMPLS Traffic Engineering.

  • Erweitertes MAM: Ein proprietäres Bandbreitenmodell, das sich ähnlich wie Standard-MAM verhält. Wenn Sie Multi-class-LSPs konfigurieren, müssen Sie das erweiterte MAM-Bandbreitenmodell konfigurieren.

  • Bandbreitenzuordnungsmodell für Russische Dolls (RDM): Ermöglicht eine effiziente Verwendung der Bandbreite, indem den Klassentypen die gemeinsame Bandbreite ermöglicht wird. RDM ist in RFC 4127 definiert, Russian Dolls Bandbreiteneinschränkungsmodell für Diffserv-orientierteMPLS Traffic Engineering.

Um ein Bandbreitenmodell zu konfigurieren, fügen Sie die Anweisung hinzu, und geben Sie bandwidth-model eine der Optionen für das Bandbreitenmodell ein:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

  • [edit protocols mpls diffserv-te]

  • [edit logical-systems logical-system-name protocols mpls diffserv-te]

    Anmerkung:

    Wenn Sie das Bandbreitenmodell auf einem Eingangsrouter ändern, werden alle auf dem Router aktivierten LSPs heruntergefahren und neusignalisiert.

Konfigurieren von Traffic Engineering-Kursen

Die Konfiguration von Traffic Engineering-Kursen ist optional. Tabelle 1 zeigt die Standardwerte für alles in der Traffic-Engineering-Klassenmatrix an. Die Standardzuordnung wird im Hinblick auf die in der Konfigurationseinstellungen festgelegten Standardweiterleitungsklassen CoS ausgedrückt.

Tabelle 1: Standardwerte für die Traffic Engineering Class Matrix

Traffic Engineering-Klasse

Klassentyp

Warteschlange

Priorität

te0

ct0

0

7

te1

ct1

1

7

te2

ct2

2

7

te3

ct3

3

7

te4

ct0

0

0

te5

ct1

1

0

te6

ct2

2

0

te7

ct3

3

0

Wenn Sie die Standardzuordnungen außer Kraft setzen möchten, können Sie die Traffic Engineering-Klassen 0 bis 7 konfigurieren. Für jede Traffic Engineering-Klasse konfigurieren Sie einen Klassentyp (oder eine Warteschlange) von 0 bis 3. Für jeden Klassentyp konfigurieren Sie eine Priorität von 0 bis 7.

Um Traffic Engineering-Klassen explizit zu konfigurieren, fügen Sie die Anweisung te-class-matrix hinzu:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten:

Im folgenden Beispiel wird gezeigt, wie die Traffic Engineering-Klasse mit dem Klassentyp und einer te0 Priorität ct14 von:

Anmerkung:

Wenn Sie einen Wert für eine der Traffic Engineering-Klassen explizit konfigurieren, werden alle Standardwerte in der Traffic Engineering-Klassenmatrix gelöscht.

Wenn Sie Traffic-Engineering-Klassen explizit konfigurieren, müssen Sie auch ein Bandbreitenmodell konfigurieren. anderenfalls schlägt der Commit-Vorgang der Konfiguration fehl.

Anforderungen und Beschränkungen für die Traffic Engineering Class Matrix

Wenn Sie eine Traffic-Engineering-Klassenmatrix konfigurieren, müssen Sie sich der folgenden Anforderungen und Beschränkungen bewusst sein:

  • Eine Zuordnungskonfiguration ist lokal und wirkt sich nur auf den Router aus, auf dem sie konfiguriert ist. Dies wirkt sich nicht auf systeme aus, die in der Domain mit differenzierten Diensten aktiv sind. Damit eine Differentiated Services-Domäne ordnungsgemäß funktioniert, müssen Sie jedoch die gleiche Traffic Engineering-Klassenmatrix auf allen Routern konfigurieren, die in der gleichen Domäne teilnehmen.

  • Bei der ausdrücklichen Konfiguration von Traffic-Engineering-Kursen müssen Sie die Klassen in der Reihenfolge ( te0 , , , und so te1te2 weiter) konfigurieren. Andernfalls schlägt der Commit-Vorgang der te3 Konfiguration fehl.

Die erste von Ihnen konfigurierte Traffic-Engineering-Klasse; te0 andernfalls schlägt der Commit-Betrieb der Konfiguration fehl.

Konfigurieren von Class of Service für DiffServ-Aware Traffic Engineering

Für das DiffServ-orientierte Traffic Engineering müssen Sie auch konfigurationen Class-of-Service. Das folgende Beispiel veranschaulicht eine Class-of-Service-Konfiguration, die jeder Klasse 25 Prozent der Verbindungsbandbreite zuteilen würde:

Konfigurieren von LSPs für DiffServ-orientiertes Traffic Engineering

Sie müssen die Domain für differenzierte Services (siehe Konfigurieren von Routern für DiffServ-Aware Traffic Engineering) konfigurieren, bevor Sie DiffServ-orientiertes Traffic-Engineeringfür LSPs aktivieren können. Die Domäne differenzierter Services bietet die zugrunde liegenden Klassentypen und die entsprechenden Traffic Engineering-Klassen, auf die Sie in der LSP-Konfiguration verweisen. Die Traffic Engineering-Klassen müssen konsequent auf jedem Router konfiguriert werden, der in der Domäne differenzierter Dienste (Differentiated Services) teilt, damit der LSP ordnungsgemäß funktioniert.

Anmerkung:

Bei der Konfiguration von DiffServ-orientiertem Traffic Engineering für LSPs müssen Sie entweder MAM oder RDM als Bandbreitenmodell konfigurieren. Siehe Konfiguration des Bandbreitenmodells.

Die tatsächlichen Daten, die über diese Differentiated Services-Domäne übertragen werden, werden durch einen LSP übertragen. Jeder LSP basiert auf den EXP-Bits MPLS Pakete, um ein DiffServ-orientiertes Traffic Engineering zu ermöglichen. Jeder LSP kann Datenverkehr für einen einzelnen Klassentyp tragen.

Alle im LSP beteiligten Router müssen Router Juniper Networks sein, auf denen Version Junos OS 6.3 oder höher ausgeführt wird. Das Netzwerk kann Router von anderen Anbietern umfassen Juniper Networks Router, auf denen frühere Versionen des Netzwerks ausgeführt Junos OS. Das DiffServ-orientierte Traffic-Engineering-LSP kann diese Router jedoch nicht durchlaufen.

Anmerkung:

Sie können nicht gleichzeitig Multiclass-LSPs und DiffServ-orientierte Traffic Engineering-LSPs auf demselben Router konfigurieren.

Um DiffServ-orientiertes Traffic-Engineering für LSPs zu ermöglichen, müssen Sie Folgendes konfigurieren:

Konfigurieren von Class-of-Service für die Schnittstellen

Die vorhandene Class-of-Service (CoS)-Infrastruktur stellt sicher, dass der durchweg gekennzeichnete Datenverkehr die Planungsgarantien für seine Klasse erhält. Klassifizierung, Kennzeichnung und Planung, die zur Erfüllung dieser Ziele erforderlich sind, werden mithilfe der vorhandenen Funktionen Junos OS CoS konfiguriert.

Anmerkung:

Die Junos OS unterstützt keine Schnittstellen CoS an ATM-Schnittstellen.

Informationen zur Konfiguration CoS Netzwerk finden Sie im Benutzerhandbuch Junos OS Class of Service für Routinggeräte.

Konfiguration IGP

Sie können entweder eine IS-IS oder OSPF als IGP. Standard IS-IS OSPF- und Konfigurationseinstellungen für Router, die LSPs unterstützen. Informationen zur Konfiguration dieser Protokolle finden Sie in der Junos OS Routing Protocols Library für Routinggeräte.

Konfigurieren von Traffic-Engineered-LSPs

Sie konfigurieren einen LSP mithilfe der standardmäßigen LSP-Konfigurations anweisungen und -verfahren. Um DiffServ-orientiertes Traffic Engineering für den LSP zu konfigurieren, geben Sie eine Bandbreiteneinschränkung des Klassentyps ein, indem Sie die Anweisung bandwidth angeben:

Eine Liste von Hierarchieebenen, in denen Sie die Anweisung enthalten können, finden Sie in den bandwidth Anweisungszusammenfassungsabschnitten dieser Anweisung.

Wenn Sie keine Bandbreite für einen Klassentyp angeben, wird automatisch als Warteschlange für den ct0 LSP angegeben. Im Gegensatz zu Multi-Class-LSPs kann für jeden LSP nur ein Klassentyp konfiguriert werden.

Die Klassentyp-Anweisungen geben die Bandbreite (in Bits pro Sekunde) für die folgenden Klassen an:

  • ct0— Bandbreite für Kurs 0 reserviert

  • ct1— Bandbreite für Kurs 1 reserviert

  • ct2— Bandbreite für Klasse 2 reserviert

  • ct3— Bandbreite für Klasse 3 reserviert

Sie können die Einrichtung und die Durchführung von Prioritäten für einen LSP konfigurieren. Die folgenden Einschränkungen gelten jedoch:

  • Die Kombination von Klasse und Priorität muss eine der konfigurierten Traffic Engineering-Klassen sein. Die Standard-Einrichtungspriorität beträgt 7 und die Standard-Holdingpriorität 0.

  • Das Konfigurieren einer ungültigen Kombination von Klassentyp und Priorität bewirkt, dass der Commit-Vorgang ausfällt.

  • Eine automatische Bandbreitenzuordnung wird nicht unterstützt. Wenn Sie die automatische Bandbreitenzuordnung konfigurieren, schlägt der Commit-Vorgang fehl.

  • Mit der Anweisung konfigurierte LSPs verwenden den Standardklassentyp, ohne bandwidth einen Klassentyp ct0 anzugeben.

  • Informationen zu Migrationsfragen finden Sie unter Internet draft-ietf-tewg-diff-te-proto-07.txt.

Konfigurieren von Überwachung für LSPs

Policing ermöglicht Ihnen die Kontrolle des Datenverkehrs, der über einen bestimmten LSP weitergeleitet wird. Durch Überwachung wird sichergestellt, dass die über einen LSP weitergeleitete Datenverkehrsmenge niemals die angeforderte Bandbreitenzuordnung überschreitet. Sie können für jeden LSP mehrere Policer konfigurieren.

Informationen zur Konfiguration eines Policers für einen LSP finden Sie unter Konfigurieren von Policern für LSPs.

Konfigurieren von Fast Reroute für Traffic-Engineered-LSPs

Sie können Fast Reroute für Traffic Engineered-LSPs (LSPs, die eine einzelne Datenverkehrsklasse tragen) konfigurieren. Es ist auch möglich, die Bandbreite auf dem Detour-Pfad für die Datenverkehrsklasse zu reservieren, wenn Fast Reroute aktiviert ist. Es wird dieselbe Klassentypnummer sowohl für den Traffic Engineered LSP als auch für seinen Detour verwendet.

Wenn Sie den Router so konfigurieren, dass er die Bandbreite für den Detour-Pfad reservieren kann, wird eine Prüfung getroffen, um sicherzustellen, dass der Link DiffServ-fähig ist, Traffic Engineering zu behandeln, und CoS-Funktionen nutzen, bevor er als möglicher Detour-Pfad akzeptiert wird. Nicht unterstützte Links werden nicht verwendet.

Sie können die Bandbreitenmenge, die Sie für Detours reservieren möchten, entweder mithilfe der bandwidth Anweisung oder der Anweisung bandwidth-percent konfigurieren. Diese Anweisungen können nur nach und nach konfiguriert werden. Wenn Sie weder die Anweisung noch die Anweisung konfigurieren, bedeutet die Standardeinstellung, keine Bandbreite für den Detour-Pfad zu reservieren (die Bandbreitengarantie geht verloren, wenn der Datenverkehr auf den bandwidthbandwidth-percent Detour-Pfad umgestellt wird).

Wenn Sie die Anweisung konfigurieren, können Sie die bestimmte Bandbreitenmenge (in Bits pro Sekunde [bps]) angeben, die Sie für den bandwidth Detour-Pfad reservieren möchten. Informationen finden Sie unter Konfigurieren von Fast Reroute.

Mit dieser Anweisung können Sie die Bandbreite des Detour-Pfads als Prozentwert der für den geschützten Pfad bandwidth-percent konfigurierten Bandbreite angeben. Wenn Sie beispielsweise 100 Millionen Bps Bandbreite für den geschützten Pfad konfigurieren und 20 für die Anweisung konfigurieren, bleibt dem Detour-Pfad 20 Millionen Bps Bandbreite für die Verwendung bandwidth-percent vorbehalten.

Geben Sie die Anweisung an, um den vom Detour-Pfad verwendeten Prozent der Bandbreite auf der Basis der Bandbreite des geschützten Pfads bandwidth-percent zu konfigurieren:

Sie können diese Aussage in den folgenden Hierarchieebenen enthalten: