Grundlegendes zu CoS IEEE 802.1p-Prioritäten für verlustfreie Datenverkehrsströme

Konfigurieren von verlustfreien Weiterleitungsklassen (Packet Drop-Attribut)

Die Junos CLI enthält den no-loss-Parameter für die Weiterleitungsklassenkonfiguration. Obwohl derselbe Name verwendet wird, ist dies nicht die verlustfreie Standardweiterleitungsklasse. Der no-verlust-Parameter ist ein Paketverlustattribut, das Sie angeben können, um eine beliebige Weiterleitungsklasse als verlustfreie Weiterleitungsklasse zu konfigurieren.

Hinweis:

Auf Switches, die unterschiedliche Weiterleitungsklassen für Unicast- und Multi-Destination-Datenverkehr verwenden, muss die Weiterleitungsklasse eine Unicast-Weiterleitungsklasse sein. Auf Switches, die dieselben Weiterleitungsklassen für Unicast- und Multi-Destination-Datenverkehr verwenden, wird nur Unicast-Datenverkehr verlustfrei behandelt.

Sie können bis zu sechs Weiterleitungsklassen (abhängig von der Systemarchitektur und der Verfügbarkeit von Systemressourcen) als verlustfreie Weiterleitungsklassen konfigurieren, indem Sie das no-loss drop-Attribut auf Hierarchieebene [edit class-of-service forwarding-classes class forwarding-class-name queue-num queue-number] einbeziehen.

Wenn Sie die standardmäßigen Weiterleitungsklassen fcoe oder no-loss verwenden, enthalten sie standardmäßig das no-loss-drop-Attribut. Wenn Sie die Weiterleitungsklassen fcoe oder no-loss explizit konfigurieren und ihr verlustfreies Verhalten beibehalten möchten, müssen Sie das drop-Attribut no-loss in die Konfiguration aufnehmen.

Hinweis:

Alle Weiterleitungsklassen, die derselben Ausgabewarteschlange zugeordnet sind, müssen das gleiche Paketverwerfungsattribut haben. Alle Weiterleitungsklassen, die derselben Ausgabewarteschlange zugeordnet sind, müssen entweder verlustbehaftet oder verlustfrei sein. Sie können nicht gleichzeitig eine verlustbehaftete und eine verlustfreie Weiterleitungsklasse derselben Warteschlange zuordnen.

Um Fate Sharing (ein überlasteter Datenstrom, der einen nicht überlasteten Datenstrom beeinflusst) zu vermeiden, verwenden Sie eine Eins-zu-Eins-Zuordnung von verlustfreien Weiterleitungsklassen zu IEEE 802.1p-Codepunkten (Prioritäten) und Warteschlangen. Ordnen Sie jede verlustfreie Weiterleitungsklasse einer anderen Warteschlange zu und klassifizieren Sie eingehenden Datenverkehr in Weiterleitungsklassen, sodass jede Weiterleitungsklasse Datenverkehr mit nur einer Priorität (Codepunkt) transportiert.

Die Weiterleitungsklassen fcoe und no-loss sind Sonderfälle, da sie in der Standardkonfiguration für verlustfreies Verhalten konfiguriert sind (vorausgesetzt, Sie aktivieren auch PFC für die Prioritäten, die den Weiterleitungsklassen fcoe und no-loss in der CNP-Eingabegruppe zugeordnet sind).

Tabelle 2 fasst die möglichen Konfigurationen der Weiterleitungsklassen fcoe und no-loss zusammen. Die Tabelle zeigt auch das Ergebnis dieser Konfigurationen in Bezug auf das verlustfreie Datenverkehrsverhalten. Bei den gezeigten Konfigurationen wird davon ausgegangen, dass PFC, DCBX und Klassifizierer ordnungsgemäß konfiguriert sind.

Für alle anderen Weiterleitungsklassen mit Ausnahme der fcoe Weiterleitungsklassen und no-loss müssen Sie den verlustfreien Transport explizit konfigurieren, indem Sie das No-Loss-Attribut Packet Drop angeben, da die Standardkonfiguration für alle anderen Weiterleitungsklassen verlustbehaftet ist.

Überlastungsbenachrichtigungsprofile (PFC-Konfiguration)

Verwenden Sie CNPs, um verlustfreie PFC-Eigenschaften auf Eingangs- und Ausgabeschnittstellen zu konfigurieren.

Die Eingabezeilengruppe eines CNP aktiviert PFC für bestimmte IEEE 802.1p-Prioritäten (Codepunkte) und verfeinert die Headroom-Puffereinstellungen durch Konfiguration des MRU-Werts und der Kabellänge an Eingangsschnittstellen.

Die Ausgabezeile eines CNP aktiviert PFC (Flusssteuerung) für Ausgabewarteschlangen für bestimmte IEEE 802.1p-Prioritäten, sodass die Warteschlangen auf PFC-Pausennachrichten vom verbundenen Peer mit der Priorität Ihrer Wahl antworten können. (Standardmäßig antworten die Ausgabewarteschlangen 3 und 4 auf empfangene PFC-Nachrichten, wenn diese Warteschlangen verlustfreien Datenverkehr in den Weiterleitungsklassen fcoe bzw. verlustfrei übertragen.)

Um einen verlustfreien Transport zu erreichen, muss die Priorität, die an den Eingangsschnittstellen angehalten wird, mit der Priorität übereinstimmen, die an den Ausgangsschnittstellen für einen bestimmten Datenverkehrsstrom angehalten wird. Wenn Sie beispielsweise Eingangsschnittstellen so konfigurieren, dass Datenverkehr mit IEEE 802.1p Priorität 5 (Codepunkt 101) angehalten wird und Datenverkehr der Priorität 5 der Ausgabewarteschlange 5 zugeordnet ist, müssen Sie auch die entsprechenden Ausgabeschnittstellen so konfigurieren, dass die Priorität 5 in Warteschlange 5 angehalten wird. Darüber hinaus muss die Weiterleitungsklasse, die Warteschlange 5 zugeordnet ist, als verlustfreie Weiterleitungsklasse konfiguriert werden (mit dem no-loss-Drop-Attribut).

VORSICHT:

Jede Änderung an der PFC-Konfiguration an einem Port blockiert vorübergehend den gesamten Port (nicht nur die Prioritäten, die von der PFC-Änderung betroffen sind), damit der Port die Änderung implementieren kann, und hebt dann die Blockierung des Ports auf. Durch das Blockieren des Ports wird der ein- und ausgehende Datenverkehr gestoppt und es kommt zu Paketverlusten in allen Warteschlangen des Ports, bis die Blockierung des Ports aufgehoben wird.

Eine Änderung der PFC-Konfiguration bedeutet jede Änderung an einem CNP, einschließlich des Änderns des Eingabeteils des CNP (Aktivieren oder Deaktivieren von PFC für eine Priorität oder Ändern der MRU- oder Kabellängenwerte) oder des Ausgabeteils des CNP, der die Ausgabeflusssteuerung für eine Warteschlange aktiviert oder deaktiviert. Eine PFC-Konfigurationsänderung wirkt sich nur auf Ports aus, die das geänderte CNP verwenden.

Die folgenden Aktionen ändern die PFC-Konfiguration:

• Löschen oder Deaktivieren einer PFC-Konfiguration (Eingabe oder Ausgabe) in einem CNP, das auf einer oder mehreren Schnittstellen verwendet wird. Zum Beispiel:

  1. Ein vorhandener CNP mit einer Eingabezeile, die PFC für die Prioritäten 3, 5 und 6 aktiviert, ist auf den Schnittstellen xe-0/0/20 und xe-0/0/21 konfiguriert.

  2. Wir deaktivieren die PFC-Konfiguration für Priorität 6 im Eingabe-CNP und bestätigen dann die Konfiguration.

  3. Die PFC-Konfigurationsänderung bewirkt, dass der gesamte Datenverkehr auf den Schnittstellen xe-0/0/20 und xe-0/0/21 angehalten wird, bis die PFC-Änderung implementiert wurde. Wenn die PFC-Änderung implementiert wurde, wird der Datenverkehr wieder aufgenommen.

• Konfigurieren eines CNP auf einer Schnittstelle. (Dadurch wird der PFC-Status geändert, indem PFC für eine oder mehrere Prioritäten aktiviert wird.)

• Löschen eines CNP aus einer Schnittstelle. (Dadurch wird der PFC-Status geändert, indem PFC für eine oder mehrere Prioritäten deaktiviert wird.)

Configuring Input Interface Flow Control (PFC and Headroom Buffer Calculation)

Auf Ethernet-Schnittstellen aktiviert die Eingangszeile des CNP PFC für bestimmte Prioritäten, sodass die Eingangsschnittstelle während Überlastungen eine Pausennachricht an den verbundenen Peer senden kann. Eingangs-CNPs verfeinern auch die Headroom-Puffer, die für die PFC-Unterstützung verwendet werden, indem sie es Ihnen ermöglichen, den MRU-Wert und die Kabellänge zu konfigurieren (wenn Sie nicht die Standardkonfiguration verwenden möchten).

Headroom-Puffer unterstützen verlustfreien Transport, indem sie den Datenverkehr speichern, der an einer Schnittstelle ankommt, nachdem die Schnittstelle eine PFC-Flusssteuerungsnachricht gesendet hat, um den eingehenden Datenverkehr zu pausieren. Bis der verbundene Peer die Flusssteuerungsmeldung empfängt und den Datenverkehr pausiert, empfängt die Schnittstelle weiterhin Datenverkehr und muss ihn puffern (und den Datenverkehr, der sich nach der Pause des Peers noch auf der Leitung befindet), um Paketverluste zu vermeiden.

Das System verwendet die MRU und die Länge des angeschlossenen physischen Kabels, um die Puffer-Headroom-Zuweisung zu berechnen. Die Standardkonfigurationswerte sind:

• MRU für Datenverkehr der Priorität 3 – 2500 Byte

• MRU für Datenverkehr der Priorität 4 – 9216 Byte

• Kabellänge – 100 Meter (ca. 328 Fuß)

Hinweis:

Wenn Sie die Flusssteuerung für eine Priorität konfigurieren, die nicht zu den Standardprioritäten für die Datenstromsteuerung gehört, beträgt der Standardwert für die Fehlerüberwachung 2500 Byte. Wenn Sie z. B. die Flusssteuerung für Priorität 5 konfigurieren und keinen MRU-Wert explizit konfigurieren, beträgt der MRU-Standardwert 2500 Byte.

Sie können die MRU und die Kabellänge verfeinern, um die Größe des Headroom-Puffers auf einer Schnittstelle anzupassen. Der Switch verfügt über einen gemeinsamen globalen Pufferpool und weist verlustfreien Warteschlangen bei Bedarf dynamisch Headroom-Pufferspeicher zu.

Eine niedrigere MRU oder eine kürzere Kabellänge verringern den auf einer Schnittstelle erforderlichen Headroom-Puffer und lassen mehr Headroom-Pufferspeicher für andere Schnittstellen. Eine höhere MRU oder eine längere Kabellänge erhöhen den auf einer Schnittstelle benötigten Headroom-Pufferspeicher und lassen weniger Headroom-Pufferspeicher für andere Schnittstellen.

In vielen Fällen können Sie die Headroom-Puffer besser nutzen, indem Sie den MRU-Wert reduzieren (z. B. ist ein MRU-Wert von 2180 für die meisten FCoE-Netzwerke ausreichend) und indem Sie den Kabellängenwert reduzieren, wenn das physische Kabel weniger als 100 Meter lang ist.

Hinweis:

Wenn Sie die Headroom-Puffer durch Ändern der MRU oder der Kabellänge konfigurieren und die Konfiguration bestätigen, führt das System eine Commit-Prüfung durch und lehnt die Konfiguration ab, wenn nicht genügend Headroom-Pufferspeicher verfügbar ist.

Das System führt jedoch keine Commit-Prüfung durch, sondern gibt stattdessen einen Syslog-Fehler zurück, wenn:

• Die Puffer sind auf einer LAG-Schnittstelle konfiguriert.

• Der Standardklassifizierer wird auf der Schnittstelle verwendet (anstelle eines vom Benutzer konfigurierten Klassifizierers).

• Die Schnittstelle wurde noch nicht erstellt.

Configuring Output Interface Flow Control (PFC)

Auf Ethernet-Schnittstellen können Sie die Ausgabezeile des CNP verwenden, um die Flusssteuerung für Ausgabewarteschlangen zu konfigurieren und die PFC-Pausenreaktion für bestimmte IEEE 802.1p-Prioritäten zu aktivieren.

Hinweis:

Auf Switches, die unterschiedliche Ausgabewarteschlangen für Unicast- und Multi-Destination-Datenverkehr verwenden, muss es sich bei der Warteschlange um eine Unicast-Ausgabewarteschlange handeln.

Standardmäßig sind die Ausgabewarteschlangen 3 und 4 für die PFC-Pause auf den Prioritäten 3 (IEEE 802.1p-Codepunkt 011) und 4 (IEEE 802.1p-Codepunkt 100) aktiviert. Die standardmäßige PFC-Pausenantwort unterstützt die standardmäßige verlustfreie Weiterleitungsklassenkonfiguration, die die fcoe-Weiterleitungsklasse Warteschlange 3 und Priorität 3 und die verlustfreie Weiterleitungsklasse Warteschlange 4 und Priorität 4 zuordnet.

Durch die Konfiguration von PFC für Ausgabewarteschlangen können Sie jede Priorität für jede Ausgabewarteschlange auf jeder Ethernet-Schnittstelle anhalten. Mit der Ausgabeflusssteuerung können Sie mehr als zwei Ausgabewarteschlangen verwenden, um verlustfreie Datenverkehrsflüsse zu unterstützen (Sie können bis zu sechs verlustfreie Weiterleitungsklassen konfigurieren und diese verlustfreien Weiterleitungsklassen verschiedenen Ausgabewarteschlangen zuordnen, die für die PFC-Pause aktiviert sind). Die Datenstromsteuerung für die Ausgabewarteschlange ermöglicht Ihnen auch die Unterstützung mehrerer verlustfreier Weiterleitungsklassen (jede ist einer anderen Priorität und Ausgabewarteschlange zugeordnet) für eine Datenverkehrsklasse.

Hinweis:

Die Ausgabeflusssteuerung funktioniert nur, wenn PFC in der CNP-Eingabezeile für die entsprechenden Prioritäten auf der Schnittstelle aktiviert ist. Wenn Sie z. B. die Ausgabeflusssteuerung für Priorität 5 aktivieren (IEEE 802.1p-Codepunkt 101), müssen Sie auch PFC im CNP für die Eingabegruppe für Priorität 5 aktivieren.

Wenn das konvergente Ethernet-Netzwerk beispielsweise zwei verschiedene Prioritäten für FCoE-Datenverkehr verwendet (z. B. Priorität 3 und Priorität 5), können Sie diese Prioritäten in verschiedene verlustfreie Weiterleitungsklassen klassifizieren, die verschiedenen Ausgabewarteschlangen zugeordnet sind:

1. Konfigurieren Sie zwei verlustfreie Weiterleitungsklassen für FCoE-Datenverkehr, wobei jede Weiterleitungsklasse einer anderen Ausgabewarteschlange zugeordnet ist. Sie können z. B. die standardmäßige fcoe-Weiterleitungsklasse verwenden, die Warteschlange 3 zugeordnet ist, und Sie können eine zweite verlustfreie Weiterleitungsklasse namens fcoe1 konfigurieren und Warteschlange 5 zuordnen. Die Weiterleitungsklasse fcoe ist für FCoE-Datenverkehr der Priorität 3 (Codepunkt 011) und die Weiterleitungsklasse fcoe1 für FCoE-Datenverkehr der Priorität 5 (Codepunkt 101).

2. Konfigurieren Sie einen Klassifizierer, der jede Weiterleitungsklasse dem gewünschten IEEE 802.1p-Codepunkt (Priorität) zuordnet. Wenn der FCoE-Datenverkehr auf beiden Prioritäten eine Schnittstelle verwendet, muss der Klassifizierer beide Weiterleitungsklassen mit den richtigen Prioritäten klassifizieren. Wenn FCoE-Datenverkehr mit unterschiedlichen Prioritäten unterschiedliche Schnittstellen verwendet, muss die Klassifiziererkonfiguration auf jeder Schnittstelle der entsprechenden verlustfreien Weiterleitungsklasse die richtige Priorität zuweisen.

3. Wenden Sie die Klassifizierung auf die Schnittstellen an, die den FCoE-Datenverkehr übertragen. Der Classifier bestimmt die Zuordnung von Weiterleitungsklassen zu Prioritäten auf jeder Schnittstelle.

Um den verlustfreien Transport für diese Weiterleitungsklassen zu konfigurieren, müssen Sie außerdem Folgendes tun:

• Aktivieren Sie PFC für die beiden Prioritäten (3 und 5 in diesem Beispiel) an den Eingangsschnittstellen in der CNP-Eingabezeilengruppe.

• Konfigurieren Sie PFC für die Ausgabewarteschlangen und Prioritäten für die Weiterleitungsklassen in der CNP-Ausgabegruppe, damit die Schnittstelle auf Pausennachrichten reagieren kann, die vom verbundenen Peer empfangen werden.

  Hinweis:

  Wenn Sie das CNP auf einer Schnittstelle konfigurieren, wird der gesamte ein- und ausgehende Datenverkehr blockiert, bis die Konfiguration implementiert ist, dann wird die Blockierung der Schnittstelle aufgehoben und der Datenverkehr wird fortgesetzt. Während der Zeit, in der die Schnittstelle blockiert ist, kommt es bei allen Warteschlangen auf der Schnittstelle zu Paketverlusten.

• Konfigurieren Sie DCBX für den Austausch von Anwendungsprotokoll-TLVs für beide FCoE-Prioritäten.

Hinweis:

Wenn Sie die Flusssteuerung nicht so konfigurieren, dass Ausgabewarteschlangen angehalten werden, verwendet die Standardkonfiguration eine Eins-zu-Eins-Zuordnung von IEEE 802.1p-Codepunkten (Prioritäten), um Warteschlangen nach Nummer auszugeben. Beispielsweise wird die Priorität 0 (Codepunkt 000) der Warteschlange 0 zugeordnet, die Priorität 1 (Codepunkt 001) wird der Warteschlange 1 zugeordnet usw. Standardmäßig sind nur die Warteschlangen 3 und 4 aktiviert, um auf Pausennachrichten vom verbundenen Peer zu reagieren, und Sie müssen PFC explizit für die entsprechenden Prioritäten in der CNP-Eingabezeilengruppe aktivieren, um verlustfreies Verhalten zu erreichen.

Wenn Sie die Standardkonfiguration nicht verwenden, müssen Sie die Ablaufsteuerung für jede Ausgabewarteschlange, die Sie für die PFC-Pause aktivieren möchten, explizit konfigurieren. Wenn Sie beispielsweise die Flusssteuerung explizit für Ausgabewarteschlange 5 konfigurieren, ist die Standardkonfiguration nicht mehr gültig, und nur die Ausgabewarteschlange 5 ist für die PFC-Pause aktiviert. Die Ausgabewarteschlangen 3 und 4 sind nicht mehr für PFC-Pause aktiviert, sodass der Datenverkehr, der diese Warteschlangen verwendet, nicht mehr auf PFC-Pausennachrichten reagiert, selbst wenn die entsprechende Weiterleitungsklasse mit dem drop-Attribut no-loss konfiguriert ist. Um die Pausenkonfiguration für die Ausgabewarteschlangen 3 und 4 beizubehalten und die Flusssteuerung für Warteschlange 5 zu konfigurieren, müssen Sie die Flusssteuerung für die Warteschlangen 3, 4 und 5 explizit konfigurieren.

Auf Switches, die unterschiedliche Ausgabewarteschlangen für Unicast- und Multi-Destination-Datenverkehr verwenden, können Sie die Flusssteuerung nicht so konfigurieren, dass eine Multi-Destination-Ausgabewarteschlange angehalten wird. Sie können die Flusssteuerung so konfigurieren, dass nur Unicast-Ausgabewarteschlangen angehalten werden. Auf Switches, die dieselben Ausgabewarteschlangen für Unicast- und Multi-Destination-Datenverkehr verwenden, wird nur Unicast-Datenverkehr verlustfrei behandelt.

Output Interface Flow Control Profiles

Durch die Konfiguration der CNP-Ausgabezeile wird ein Ausgabe-Flusssteuerungsprofil erstellt, das den Ausgangsports die Warteschlangen mitteilt, auf die die Ethernet-Schnittstelle auf PFC-Pausenmeldungen reagieren soll.

Das System verfügt über ein standardmäßiges Ausgabe-Flusssteuerungsprofil, das auf alle Ethernet-Schnittstellen angewendet wird, wenn das an die Schnittstelle angeschlossene CNP nur eine Eingabezeilengruppe und keine Ausgabezeilengruppe enthält. Das Standardprofil reagiert auf PFC-Pausennachrichten, die in Warteschlange 3 (für Priorität 3 für die standardmäßige fcoe-Weiterleitungsklasse) und in Warteschlange 4 (für Priorität 4 für die standardmäßige verlustfreie Weiterleitungsklasse) empfangen werden, und ist nur wirksam, wenn PFC für diese Prioritäten in der CNP-Eingabegruppe konfiguriert ist.

Darüber hinaus verfügt das System über zwei interne Ausgabe-Flusssteuerungsprofile, die es automatisch auf Fabric-Ports (FTE) und auf native FC-Schnittstellen (NP_Ports) anwendet.

Da ein Ausgangs-CNP die PFC-Pausenantwort für mehrere Ausgabewarteschlangen (Prioritäten) konfigurieren kann, ist ein vom Benutzer konfigurierbarer Ausgabe-CNP in der Regel flexibel genug, um die gewünschte PFC-Antwort auf allen programmierten Schnittstellen anzugeben.

Hinweis:

Jeder Port kann ein Ausgangs-Flusssteuerungsprofil verwenden. Sie können nicht mehr als ein Profil auf einen Port anwenden.

Ausgabeflusssteuerungsprofile können im Tabellenformat ausgedrückt werden. Tabelle 3 zeigt beispielsweise das Standardprofil für die Ablaufsteuerung der Ausgabe, das die Prioritäten 3 und 4 für die Warteschlangen 3 und 4 anhält (denken Sie daran, dass PFC auch für die Codepunkte 3 und 4 in der CNP-Eingabegruppe aktiviert sein muss, damit PFC funktioniert):

Tabelle 4 ist ein Beispiel für ein vom Benutzer konfiguriertes Ausgabe-Flusssteuerungsprofil. Im Beispiel aus dem vorherigen Abschnitt konfiguriert die CNP-Ausgabegruppe die Flusssteuerung für die Ausgabewarteschlange 5 und auch explizit die Ausgabeflusssteuerung für die Warteschlangen 3 und 4 für die Weiterleitungsklassen fcoe und no-loss. (Wenn Sie explizit ein Ausgabe-CNP konfigurieren, müssen Sie jede Ausgabewarteschlange, die auf PFC-Nachrichten antworten soll, explizit konfigurieren, da das vom Benutzer konfigurierte Profil das Standardprofil überschreibt. Wenn dieses Beispiel die Warteschlangen 3 und 4 nicht enthalten würde, würden diese Warteschlangen nicht mehr auf empfangene PFC-Nachrichten antworten.)

Denken Sie daran, dass Sie PFC auch für die Codepunkte 3, 4 und 5 in der CNP-Eingabegruppe aktivieren müssen, damit diese Konfiguration funktioniert. Wenn Sie das CNP auf einer Schnittstelle konfigurieren, wird der gesamte ein- und ausgehende Datenverkehr blockiert, bis die Konfiguration implementiert ist, dann wird die Blockierung der Schnittstelle aufgehoben und der Datenverkehr wird fortgesetzt. Während der Zeit, in der die Schnittstelle blockiert ist, kommt es bei allen Warteschlangen auf der Schnittstelle zu Paketverlusten.

Configuring PFC Across Layer 3 Interfaces

Die Aktivierung von PFC für Datenverkehrsströme basiert auf dem IEEE 802.1p-Codepunkt (Priorität) im Feld Prioritätscodepunkt (PCP) des Ethernet-Frame-Headers (manchmal auch als CoS-Bits bezeichnet). Um PFC für Datenverkehr zu aktivieren, der L3-Schnittstellen passiert, muss der Datenverkehr nach seinem IEEE 802.1p-Codepunkt klassifiziert werden, nicht nach seinem DSCP-Codepunkt (oder DSCP-IPv6).

Eine konzeptionelle Übersicht darüber, wie Sie PFC für Datenverkehr über L3-Schnittstellen hinweg aktivieren können, finden Sie unter Grundlegendes zur PFC-Funktionalität in Layer 3-Schnittstellen . Ein Beispiel für die Konfiguration von PFC für Datenverkehr, der L3-Schnittstellen passiert, finden Sie unter Beispiel: Konfigurieren von PFC über Layer 3-Schnittstellen hinweg.

DCBX (Anwendungsprotokoll TLV Exchange) konfigurieren

Für Anwendungen, die einen verlustfreien Transport erfordern, tauscht DCBX Anwendungsprotokoll-TLVs mit der angeschlossenen Peer-Schnittstelle aus. Standardmäßig kündigt DCBX FCoE-Anwendungsprotokoll-TLVs auf allen Schnittstellen an, die für DCBX aktiviert sind, und standardmäßig ist DCBX auf allen Schnittstellen aktiviert. DCBX kündigt standardmäßig keine anderen Anwendungen an.

Für jede Anwendung (z. B. iSCSI), die Sie für den verlustfreien Transport konfigurieren möchten, müssen Sie die Schnittstellen aktivieren, die diesen Anwendungsdatenverkehr übertragen, um DCBX-Protokoll-TLVs mit dem verbundenen Peer auszutauschen. Der TLV-Austausch ermöglicht es den Peer-Schnittstellen, eine kompatible Konfiguration zur Unterstützung der Anwendung auszuhandeln.

Wenn Sie DCBX so konfigurieren, dass eine beliebige Anwendung angekündigt wird, wird die standardmäßige DCBX-Ankündigung überschrieben, und DCBX kündigt nur die konfigurierten Anwendungen an. Wenn Sie möchten, dass eine Schnittstelle nur die FCoE-Anwendung ankündigt, müssen Sie den DCBX-Anwendungsprotokoll-TLV-Austausch nicht konfigurieren. Stattdessen können Sie die Standardkonfiguration verwenden.

Wenn DCBX andere Anwendungen ankündigen soll, müssen Sie explizit eine Anwendungszuordnung konfigurieren und auf die Schnittstellen anwenden, auf denen Sie Protokoll-TLVs für diese Anwendungen austauschen möchten. Wenn Sie zusätzlich zu anderen Anwendungsprotokoll-TLVs auch FCoE-Anwendungsprotokoll-TLVs austauschen möchten, müssen Sie die FCoE-Anwendung auch explizit in der Anwendungszuordnung konfigurieren. DCBX Application Protocol verstehen TLV Exchange beschreibt, wie die Anwendungszuordnung funktioniert.

Hinweis:

Für den verlustfreien Transport ist es außerdem erforderlich, dass Sie PFC mit der richtigen Priorität (IEEE 802.1p-Codepunkt) auf den Eingangsschnittstellen mithilfe eines Eingabe-CNP aktivieren. Wenn die Priorität, die Sie an den Eingangsschnittstellen anhalten, nicht Warteschlange 3 oder Warteschlange 4 zugeordnet ist (die beiden Ausgabewarteschlangen, die standardmäßig für die PFC-Pausenflusssteuerung aktiviert sind), müssen Sie auch die Ausgabewarteschlangen, die den angehaltenen Eingabeprioritäten entsprechen, mithilfe der Ausgabezeile des CNP anhalten.

Schicksalsteilung zwischen Datenverkehrsklassen

Sie können verschiedene verlustfreie (oder verlustbehaftete) Datenverkehrsströme so konfigurieren, dass sie sich das Schicksal teilen, d. h. die gleiche CoS-Behandlung erhalten.

Fate Sharing ist für die E/A-Konvergenz nicht wünschenswert. Anstelle einer unabhängigen Kontrolle des Schicksals jeder Art von Fluss werden verschiedene Arten von Flüssen die gleiche Behandlung erhalten. Fate Sharing ist besonders bei verlustfreien Strömen unerwünscht. Wenn bei einem verlustfreien Datenstrom eine Überlastung auftritt und angehalten werden muss, wirkt sich dies auf Datenströme aus, die ihr Schicksal mit dem überlasteten Datenstrom teilen, auch wenn die anderen Datenströme nicht überlastet sind, und kann auch zu einer Überlastung des Eingangsports führen. Wenn Ihr Netzwerk erfordert, dass alle 802.1p-Prioritäten verlustfrei sind, können Sie dies erreichen, indem Sie eine gewisse Schicksalsteilung zwischen den acht Prioritäten zulassen, indem Sie sie auf bis zu sechs verlustfreie Weiterleitungsklassen verteilen.

Wenn die Anzahl der verlustfreien Prioritäten kleiner oder gleich der Anzahl der konfigurierten verlustfreien Weiterleitungsklassen ist, können Sie die Fate Sharing vermeiden, indem Sie eine Eins-zu-Eins-Zuordnung von Weiterleitungsklassen zu IEEE 802.1p-Codepunkten (Prioritäten) und Ausgabewarteschlangen konfigurieren. (Jede Weiterleitungsklasse sollte einer anderen Ausgabewarteschlange zugeordnet und einer anderen Priorität zugeordnet werden.)

Wenn Sie verschiedene Datenverkehrsflüsse so konfigurieren möchten, dass sie das Schicksal teilen, werden zwei Konfigurationen unterstützt: Zuordnen einer Weiterleitungsklasse zu mehr als einem IEEE 802.1p-Codepunkt (Priorität) und Zuordnen von zwei Weiterleitungsklassen zur selben Ausgabewarteschlange:

1. Wenn Sie eine verlustfreie Weiterleitungsklasse mehr als einer Priorität zuordnen, verwendet der Datenverkehr, der mit jeder der Prioritäten markiert ist, dieselben CoS-Eigenschaften, die zugeordnet sind (die CoS-Eigenschaften, die der Weiterleitungsklasse zugeordnet sind). Wenn Sie beispielsweise eine Weiterleitungsklasse namens fc1 konfigurieren, sie Warteschlange 1 zuordnen und sie den Codepunkten 101 und 110 mit einem Klassifizierer namens classify1 zuordnen, führt dies dazu, dass der Datenverkehr, der mit den Prioritäten 101 und 110 gekennzeichnet ist, das Schicksal teilt:

   Wenn in diesem Fall der Datenverkehr, der einer der beiden Prioritäten zugeordnet ist, überlastet ist, werden beide Prioritäten angehalten, da sie derselben Weiterleitungsklasse zugeordnet sind und daher ähnlich behandelt werden.

2. Wenn Sie mehrere verlustfreie Weiterleitungsklassen derselben Ausgabewarteschlange zuordnen, verwendet der den Weiterleitungsklassen zugeordnete Datenverkehr dieselbe Ausgabewarteschlange. Dadurch erhöht sich der Datenverkehr in der Warteschlange und es kann zu Überlastungen kommen, die sich auf alle Datenverkehrsströme auswirken, die der Warteschlange zugeordnet sind. Wenn Sie beispielsweise zwei Weiterleitungsklassen namens fc1 und fc2 konfigurieren, beide Weiterleitungsklassen Warteschlange 1 zuordnen und die Weiterleitungsklassen den Codepunkten 101 bzw. 110 mit einem Klassifizierer namens classify1 zuordnen, wird der mit den Prioritäten 101 und 110 markierte Datenverkehr in derselben Ausgabewarteschlange geteilt:

   In diesem Fall wirkt sich eine Überlastung der anderen Weiterleitungsklasse auf die andere Weiterleitungsklasse aus, obwohl die beiden Weiterleitungsklassen unterschiedliche IEEE 802.1p-Prioritäten verwenden. Der Grund dafür ist, dass, wenn die Ausgabewarteschlange aufgrund von Überlastung in einer der beiden Weiterleitungsklassen angehalten wird, der gesamte Datenverkehr, der diese Warteschlange verwendet, angehalten wird. Da beide Weiterleitungsklassen der Warteschlange zugeordnet sind, wird der beiden Weiterleitungsklassen zugeordnete Datenverkehr angehalten.

   Hinweis:

   Wenn Sie einer Warteschlange mehr als eine Weiterleitungsklasse zuordnen, müssen alle derselben Warteschlange zugeordneten Weiterleitungsklassen dasselbe Paketverwerfungsattribut aufweisen (alle Weiterleitungsklassen müssen verlustbehaftet sein, oder alle einer Warteschlange zugeordneten Weiterleitungsklassen müssen verlustfrei sein).

Transit-Switch-Konfiguration im Vergleich zur FCoE-FC-Gateway-Konfiguration

Auf einem Transit-Switch (alle Ethernet-Ports, keine nativen FC-Ports), der FCoE-Datenverkehr (oder anderen Datenverkehr, der verlustfreien Transport über das Ethernet-Netzwerk erfordert) weiterleitet, ist die Konfiguration von Klassifizierern, verlustfreien Weiterleitungsklassen, DCBX und PFC auf Eingangs- und Ausgangsschnittstellen zur Unterstützung eines verlustfreien Transports wie in diesem Dokument beschrieben.

Wenn ein Switch als FCoE-FC-Gateway fungiert (sofern native FC-Schnittstellen auf Ihrem Switch unterstützt werden), verwendet das System native FC-Schnittstellen (NP_Ports), um eine Verbindung mit dem FC-Switch (oder FCoE Weiterleitung) am FC Netzwerk-Edge herzustellen. CNPs oder DCBX können nicht auf native FC-Schnittstellen angewendet werden, sondern nur auf Ethernet-Schnittstellen.

Auf einem FCoE-FC-Gateway ist die Ethernet-Schnittstellenkonfiguration von Klassifizierern, DCBX und PFC identisch mit der Ethernet-Schnittstellenkonfiguration eines Transit-Switches. Die Konfiguration der verlustfreien Weiterleitungsklassen ist ebenfalls gleich.

Die Unterstützung des verlustfreien Transports auf nativen FC-Schnittstellen erfordert jedoch, dass Sie den IEEE 802.1p-Prioritätswert neu schreiben , wenn Ihr Netzwerk eine andere Priorität als 3 (IEEE-Codepunkt 011) für FCoE-Datenverkehr verwendet. Wenn Ihr Netzwerk Priorität 3 für FCoE-Datenverkehr verwendet, können und sollten Sie die Standardkonfiguration auf nativen FC-Schnittstellen verwenden.

Native FC-Schnittstellen kennzeichnen Pakete standardmäßig mit Priorität 3, wenn sie die eingehenden FC-Pakete im Ethernet einkapseln. Wenn Ihr FCoE-Netzwerk eine andere Priorität als 3 für FCoE-Datenverkehr verwendet, müssen Sie den Prioritätswert in den Wert umschreiben, den Ihr Netzwerk auf der FC-Schnittstelle verwendet, den FCoE-Datenverkehr auf den Ethernet-Schnittstellen auf die richtige Priorität klassifizieren und PFC für die richtige Priorität auf den Ethernet-Schnittstellen aktivieren, wie unter Grundlegendes zur Neuzuordnung von CoS IEEE 802.1p Priorität auf einem FCoE-FC-Gateway beschrieben.

Konfigurationsergebnisse und Commit-Prüfungen

Unterschiedliche Konfigurationen von Weiterleitungsklassen und deren Drop-Attributen, Klassifizierern, CNPs (PFC-Flusssteuerung) und Ethernet-PAUSE (IEEE 802.3X-Flusskontrolle) führen zu unterschiedlichem Systemverhalten.

Tabelle 5 beschreibt die Ergebnisse der jeweils möglichen verlustfreien Transportkonfigurationen. In der Spalte Ergebnis wird davon ausgegangen, dass die Berechnung des Pufferspielraums des Systems zu einer erfolgreichen Konfiguration geführt hat.

Wenn das System jedoch berechnet, dass nicht genügend Pufferspeicher zur Unterstützung der Konfiguration vorhanden ist, verhindert eine Commit-Prüfung, dass Sie die Konfiguration auf einer einzelnen Ethernet-Schnittstelle festschreiben. Bei LAG-Schnittstellen gibt das System keinen Commit-Check-Fehler, sondern eine Syslog-Meldung aus.

Hinweis:

Nachdem Sie den verlustfreien Transport für eine LAG-Schnittstelle konfiguriert haben, überprüfen Sie die Syslog-Meldungen, um zu bestätigen, dass der Commit erfolgreich war.

Hinweis:

Wenn Sie versuchen, sowohl PFC als auch Ethernet PAUSE für eine Verbindung zu konfigurieren, gibt das System einen Commit-Fehler zurück. PFC und Ethernet PAUSE sind sich gegenseitig ausschließende Konfigurationen auf einer Schnittstelle.