Understanding CoS IEEE 802.1p Priorities for Lossless Traffic Flows

Konfigurieren verlustfreier Weiterleitungsklassen (Packet Drop-Attribut)

Junos OS Version 12.3 führte den verlustfreien Parameter für die Weiterleitungsklassenkonfiguration ein. (Obwohl der gleiche Name verwendet wird, ist dies nicht die Standardweiterleitungsklasse ohne Verlust. Es ist ein Packet Drop-Attribut, das Sie angeben können, um jede Weiterleitungsklasse als verlustfreie Weiterleitungsklasse zu konfigurieren.)

Hinweis:

Auf Switches, die unterschiedliche Weiterleitungsklassen für Unicast- und Multidestination-Datenverkehr verwenden, muss die Weiterleitungsklasse eine Unicastweiterleitungsklasse sein. Auf Switches, die die gleichen Weiterleitungsklassen für Unicast- und Multidestinationsverkehr 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 der [edit class-of-service forwarding-classes class forwarding-class-name queue-num queue-number] Hierarchieebene einfügen.

Wenn Sie die Standard-Fcoe- oder No-Loss-Weiterleitungsklassen verwenden, enthalten sie standardmäßig das Drop-Attribut no-loss. Wenn Sie die Fcoe- oder No-Loss-Weiterleitungsklassen explizit konfigurieren und deren verlustfreies Verhalten beibehalten möchten, müssen Sie das Drop-Attribut "no-loss" in die Konfiguration aufnehmen.

Hinweis:

Alle Derselben Ausgabewarteschlange zugeordneten Weiterleitungsklassen müssen über das gleiche Packet Drop-Attribut verfügen. (Alle Derselben Ausgabewarteschlange zugeordneten Weiterleitungsklassen müssen verlust- oder verlustfrei sein. Sie können sowohl eine verlustfreie als auch eine verlustfreie Weiterleitungsklasse nicht derselben Warteschlange zuordnen.)

Verwenden Sie eine One-to-One-Zuordnung verlustfreier Weiterleitungsklassen zu IEEE 802.1p-Codepunkten (Prioritäten) und Warteschlangen, um das Teilen des Schicksals zu vermeiden (ein überlasteter Fluss, der sich auf einen nicht gespeicherten Datenfluss auswirkt). 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 Fcoe- und No-Loss-Weiterleitungsklassen sind Sonderfälle, da sie in der Standardkonfiguration für verlustfreies Verhalten konfiguriert sind (sofern Sie PFC auch für die den Fcoe- und No-Loss-Weiterleitungsklassen in der CNP-Eingangsstanz zugeordneten Prioritäten aktivieren).

Tabelle 2 fasst die möglichen Konfigurationen der Fcoe- und No-Loss-Weiterleitungsklassen in Junos OS Version 12.3 und höher zusammen und das Ergebnis dieser Konfigurationen in Bezug auf verlustfreies Datenverkehrsverhalten. Es wird davon ausgegangen, dass PFC, DCBX und Klassifizierer ordnungsgemäß konfiguriert sind.

Für alle anderen Weiterleitungsklassen außer den fcoe no-loss Weiterleitungsklassen müssen Sie den verlustfreien Transport explizit konfigurieren, indem Sie das Paketverlustattribut ohne Verlust angeben, da die Standardkonfiguration für alle anderen Weiterleitungsklassen verlustfrei ist (das Paketverlustattribut ohne Verlust wird nicht angewendet).

Überlastungsbenachrichtigungsprofile (PFC-Konfiguration)

Verwenden Sie CNPs, um verlustfreie PFC-Eigenschaften an Ein- und Ausgabeschnittstellen zu konfigurieren.

Die Eingangsstanze eines CNP ermöglicht PFC auf den angegebenen IEEE 802.1p-Prioritäten (Codepunkten) und fein abgestimmte Kopfraumpuffereinstellungen, indem der Maximum Receive Unit (MRU)-Wert und die Kabellänge an Eingangsschnittstellen konfiguriert werden.

Die Ausgangsstanze eines CNP ermöglicht PFC (Flow Control) in Ausgabewarteschlangen für bestimmte IEEE 802.1p-Prioritäten, sodass die Warteschlangen auf PFC-Pausenmeldungen vom angeschlossenen Peer auf die Priorität Ihrer Wahl reagieren können. (Die Ausgabewarteschlangen 3 und 4 reagieren standardmäßig auf empfangene PFC-Nachrichten, wenn diese Warteschlangen verlustfreien Datenverkehr in den FCOE- bzw. verlustfreien Weiterleitungsklassen übertragen.)

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

VORSICHT:

Jede Änderung der PFC-Konfiguration an einem Port blockiert vorübergehend den gesamten Port (nicht nur die von der PFC-Änderung betroffenen Prioritäten), sodass der Port die Änderung implementieren kann, und entsperrt dann den Port. Das Blockieren des Ports stoppt den eingehenden und ausgehenden Datenverkehr und verursacht Paketverluste in allen Warteschlangen auf dem Port, bis der Port freigehalten wird.

Eine Änderung der PFC-Konfiguration bedeutet jede Änderung an einem CNP, einschließlich der Änderung des Eingangsteils des CNP (Aktivieren oder Deaktivieren von PFC bei einer Priorität oder Ändern der MRU- oder Kabellängenwerte) oder Ändern des Ausgabeteils des CNP, der die Ausgabeflusssteuerung in einer Warteschlange aktiviert oder deaktiviert. Eine PFC-Konfigurationsänderung betrifft nur Ports, die das geänderte CNP verwenden.

Die folgenden Aktionen ändern die PFC-Konfiguration:

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

  1. Ein vorhandenes CNP mit einem Eingabeabschnitt, der PFC auf den Prioritäten 3, 5 und 6 ermöglicht, wird an 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 an den Schnittstellen xe-0/0/20 und xe-0/0/21 gestoppt wird, bis die PFC-Änderung implementiert ist. 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 auf einer oder mehreren Prioritäten aktiviert wird.)

• Löschen eines CNP von einer Schnittstelle. (Dadurch wird der PFC-Status geändert, indem PFC auf einer oder mehreren Prioritäten deaktiviert wird.)

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

Auf Ethernet-Schnittstellen ermöglicht die Eingangsstanze des CNP PFC auf bestimmten Prioritäten, sodass die Eingangsschnittstelle eine Pausennachricht an den angeschlossenen Peer während Überlastungsphasen senden kann. Die Eingangs-CNPs stimmen auch die für die PFC-Unterstützung verwendeten Headroom-Puffer ab, indem Sie den MRU-Wert und die Kabellänge konfigurieren können (wenn Sie die Standardkonfiguration nicht verwenden möchten).

Headroom-Puffer unterstützen verlustfreie Übertragungen, indem sie den Datenverkehr speichern, der an einer Schnittstelle ankommt, nachdem die Schnittstelle eine PFC-Flow Control-Nachricht sendet, um den eingehenden Datenverkehr anzuhalten. Bis der verbundene Peer die Datenstromsteuerungsnachricht empfängt und den Datenverkehr anhält, empfängt die Schnittstelle weiterhin Datenverkehr und muss ihn puffern (und den Datenverkehr, der sich nach den Peer-Pausen noch auf dem Draht befindet), um Paketverluste zu verhindern.

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

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

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

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

Hinweis:

Wenn Sie flow control für eine Priorität konfigurieren, die nicht zu den Standard-Flusssteuerungsprioritäten gehört, beträgt der Mru-Standardwert 2500 Bytes. Wenn Sie beispielsweise die Flusssteuerung für Priorität 5 konfigurieren und keinen MRU-Wert explizit konfigurieren, beträgt der MrU-Standardwert 2500 Bytes.

Sie können die MRU und die Kabellänge genau abstimmen, um die Größe des Kopfraumpuffers an einer Schnittstelle anzupassen. Der Switch verfügt über einen gemeinsam genutzten globalen Pufferpool und weist verlustfreien Warteschlangen nach Bedarf dynamisch Kopffreiheitspuffer zu.

Eine geringere MRU oder eine kürzere Kabellänge reduziert den an einer Schnittstelle erforderlichen Kopffreiheitspuffer und lässt mehr Platz für kopfbelassene Puffer für andere Schnittstellen. Eine höhere MRU oder eine längere Kabellänge erhöht den an einer Schnittstelle benötigten Headroom-Pufferplatz und lässt für andere Schnittstellen weniger Platz im Kopfbereich.

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

Hinweis:

Wenn Sie die Headroom-Puffer durch Ändern der MRU- oder Kabellänge konfigurieren und die Konfiguration bestätigen, führt das System eine Commit-Prüfung durch und lehnt die Konfiguration ab, wenn kein ausreichender Pufferspeicher zur Verfügung steht.

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

• Die Puffer werden auf einer LAG-Schnittstelle konfiguriert.

• Der Standardklassifizierer wird auf der Schnittstelle (anstelle eines benutzerkonfigurierten Klassifizierers) verwendet.

• Die Schnittstelle wurde noch nicht erstellt.

Configuring Output Interface Flow Control (PFC)

An Ethernet-Schnittstellen können Sie die Ausgabe-Stanza des CNP verwenden, um die Flusskontrolle in Ausgabewarteschlangen zu konfigurieren und PFC-Pausenreaktionen auf bestimmten IEEE 802.1p-Prioritäten zu aktivieren.

Hinweis:

Auf Switches, die verschiedene Ausgabewarteschlangen für Unicast- und Multidestinationsverkehr verwenden, muss die Warteschlange eine Unicast-Ausgabewarteschlange sein.

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

Die Konfiguration von PFC in Ausgabewarteschlangen ermöglicht es Ihnen, jede Priorität in jeder Ausgabewarteschlange auf jeder Ethernet-Schnittstelle anzuhalten. Mit output flow control können Sie mehr als zwei Ausgabewarteschlangen zur Unterstützung verlustfreier Datenströme verwenden (Sie können bis zu sechs verlustfreie Weiterleitungsklassen konfigurieren und sie verschiedenen Ausgabewarteschlangen zuordnen, die für DIE PFC-Pause aktiviert sind). Die Ausgabewarteschlangen-Flusssteuerung ermöglicht Ihnen auch die Unterstützung mehrerer verlustfreier Weiterleitungsklassen (die jeweils einer anderen Prioritäts- und Ausgabewarteschlange zugeordnet werden) für eine Datenverkehrsklasse.

Hinweis:

Die Output Flow Control funktioniert nur, wenn PFC in der CNP-Eingangsstanze auf den entsprechenden Prioritäten an der Schnittstelle aktiviert ist. Wenn Sie beispielsweise die Ausgabeflusssteuerung für Priorität 5 (IEEE 802.1p-Codepunkt 101) aktivieren, müssen Sie PFC auch im CNP auf der Eingangsstanz auf Priorität 5 aktivieren.

Wenn das konvergierte 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 werden:

1. Konfigurieren Sie zwei verlustfreie Weiterleitungsklassen für FCoE-Datenverkehr, wobei jede Weiterleitungsklasse einer anderen Ausgabewarteschlange zugeordnet wird. Beispielsweise könnten Sie die Standard-Fcoe-Weiterleitungsklasse verwenden, die Warteschlange 3 zugeordnet ist, und Sie könnten eine zweite verlustfreie Weiterleitungsklasse namens fcoe1 konfigurieren und sie der Warteschlange 5 zuordnen. Die Fcoe-Weiterleitungsklasse ist für Priorität 3 FCoE-Datenverkehr (Codepunkt 011) und die fcoe1-Weiterleitungsklasse für Priorität 5 (Codepunkt 101) FCoE-Datenverkehr.

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

3. Wenden Sie den Klassifizierer auf die Schnittstellen an, die FCoE-Datenverkehr übertragen. Der Klassifizierer 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:

• Aktivieren Sie PFC auf den beiden Prioritäten (in diesem Beispiel 3 und 5) an den Eingangsschnittstellen in der CNP-Eingangsstanze.

• Konfigurieren Sie PFC in den Ausgabewarteschlangen und -prioritäten für die Weiterleitungsklassen in der CNP-Ausgabes stanza, damit die Schnittstelle auf Pausenmeldungen reagieren kann, die vom verbundenen Peer empfangen wurden.

  Anmerkung:

  Wenn Sie das CNP auf einer Schnittstelle konfigurieren, wird der gesamte eingehende und ausgehende Datenverkehr blockiert, bis die Konfiguration implementiert ist, dann wird die Schnittstelle deaktiviert und der Datenverkehr wird fortgesetzt. Während der Zeit, in der die Schnittstelle blockiert wird, treten in allen Warteschlangen an der Schnittstelle Paketverluste auf.

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

Hinweis:

Wenn Sie flow control nicht so konfigurieren, dass Ausgabewarteschlangen unterbrochen werden, verwendet die Standardkonfiguration eine One-to-One-Zuordnung von IEEE 802.1p-Codepunkten (Prioritäten) zu Ausgabewarteschlangen nach Nummer. Beispielsweise wird Priorität 0 (Codepunkt 000) der Warteschlange 0 zugeordnet, Priorität 1 (Codepunkt 001) der Warteschlange 1 usw. zugeordnet. Standardmäßig sind nur Warteschlangen 3 und 4 aktiviert, um auf Pausenmeldungen des verbundenen Peers zu reagieren, und Sie müssen PFC auf den entsprechenden Prioritäten in der CNP-Eingangsstanze explizit aktivieren, um verlustfreies Verhalten zu erzielen.

Wenn Sie die Standardkonfiguration nicht verwenden, müssen Sie die Datenstromsteuerung in jeder Ausgabewarteschlange, die Sie für die PFC-Pause aktivieren möchten, explizit konfigurieren. Wenn Sie beispielsweise die Datenstromsteuerung in Ausgabewarteschlange 5 explizit konfigurieren, ist die Standardkonfiguration nicht mehr gültig, und nur die Ausgabewarteschlange 5 ist für die PFC-Pause aktiviert. Ausgabewarteschlangen 3 und 4 sind für PFC-Pausen nicht mehr aktiviert, sodass der Datenverkehr, der diese Warteschlangen verwendet, nicht mehr auf PFC-Pausenmeldungen reagiert, selbst wenn die entsprechende Weiterleitungsklasse mit dem verlustfreien Drop-Attribut konfiguriert ist. Um die Pausenkonfiguration in den Ausgabewarteschlangen 3 und 4 beizubehalten und die Datenstromkontrolle in Warteschlange 5 zu konfigurieren, müssen Sie die Datenstromsteuerung in den Warteschlangen 3, 4 und 5 explizit konfigurieren.

Auf Switches, die verschiedene Ausgabewarteschlangen für Unicast- und Multidestinationsverkehr verwenden, können Sie die Datenflusssteuerung nicht so konfigurieren, dass eine Ausgabewarteschlange mit mehreren Endpunkten angehalten wird. Sie können die Datenstromsteuerung so konfigurieren, dass nur Unicast-Ausgabewarteschlangen angehalten werden. Auf Switches, die die gleichen Ausgabewarteschlangen für Unicast- und Multidestination-Datenverkehr verwenden, wird nur Unicast-Datenverkehr verlustfrei behandelt.

Output Interface Flow Control Profiles

Die Konfiguration der CNP-Ausgangsstanz erstellt ein Output Flow Control-Profil, das den Ausgangsports die Warteschlangen angibt, auf denen die Ethernet-Schnittstelle auf PFC-Pausenmeldungen reagieren soll. Obwohl Sie eine unbegrenzte Anzahl von CNPs erstellen können, die nur Eingabe-Stanzas enthalten, ist die Anzahl der CNPs, die Sie mit Ausgabe-Stanzas konfigurieren können, begrenzt:

• Für eigenständige Switches, die nicht Teil eines QFabric-Systems sind, können Sie bis zu zwei Datenstromsteuerungsprofile für die Ausgabeschnittstelle konfigurieren. (Sie können bis zu zwei CNPs mit Ausgangsstanzen konfigurieren.)

• Bei QFabric-Systemen können Sie pro Knotengerät ein Datenstromsteuerungsprofil für die Ausgabeschnittstelle konfigurieren. (Sie können ein CNP mit einer Ausgangsstanz pro Node-Gerät konfigurieren.)

Insgesamt gibt es vier Output Flow Control-Profile.

Das System verfügt über ein Standard-Output Flow Control-Profil, das auf alle Ethernet-Schnittstellen angewendet wird, wenn das an die Schnittstelle angeschlossene CNP nur eine Eingangsstanze hat und keine Ausgabe-Stanza enthält. Das Standardprofil reagiert auf PFC-Pausenmeldungen, die in Warteschlange 3 (für Priorität 3, für die Standard-Fcoe-Weiterleitungsklasse) und in Warteschlange 4 (für Priorität 4, für die standardmäßig verlustfreie Weiterleitungsklasse) empfangen werden, und ist nur wirksam, wenn PFC auf diesen Prioritäten im CNP-Eingangs-Stanza konfiguriert ist.

Darüber hinaus verfügt das System über zwei interne Output Flow Control-Profile, die automatisch auf Fabric-Ports (FTE) und native FC-Schnittstellen (NP_Ports) angewendet werden. Wenn der Switch nicht Teil eines QFabric-Systems ist, ist das Profil, das normalerweise für FTE-Ports verwendet wird, für die Benutzerkonfiguration verfügbar und bietet ein zweites benutzerkonfigurierbares Profil. (Aus diesem Grund verfügen eigenständige Switches über zwei benutzerkonfigurierbare Output Flow Control-Profile, aber Node-Geräte in einem QFabric-System haben nur ein vom Benutzer konfigurierbares Ausgabeflusssteuerungsprofil.)

Da ein Ausgabe-CNP die PFC-Pausenantwort in mehreren Ausgabewarteschlangen (Prioritäten) konfigurieren kann, ist ein benutzerkonfigurierbares Ausgabe-CNP in der Regel flexibel genug, um die gewünschte PFC-Antwort auf allen programmierten Schnittstellen anzugeben.

Hinweis:

Jeder Port kann ein Output Flow Control-Profil verwenden. Sie können nicht mehr als ein Profil auf einen Port anwenden.

Die Profile der Ausgabeflusssteuerung können im Tabellenformat ausgedrückt werden. Tabelle 3 zeigt beispielsweise das Standard-Ausgabeflusssteuerungsprofil, das die Prioritäten 3 und 4 in den Warteschlangen 3 und 4 angehalten hat (denken Sie daran, dass PFC auch an den Codepunkten 3 und 4 in der CNP-Eingangsstanze aktiviert werden muss, damit PFC funktioniert):

Tabelle 4 ist ein Beispiel für ein benutzerkonfiguriertes Ausgabeflusssteuerungsprofil. Im Beispiel aus dem vorstehenden Abschnitt konfiguriert die CNP-Ausgangsstanz die Flusssteuerung in der Ausgabewarteschlange 5 und konfiguriert die Ausgabeflusssteuerung auch explizit in Warteschlangen 3 und 4 für die Fcoe- und verlustfreien Weiterleitungsklassen. (Wenn Sie eine Ausgabe-CNP explizit konfigurieren, müssen Sie jede Ausgabewarteschlange, die Sie auf PFC-Nachrichten reagieren möchten, explizit konfigurieren, da das benutzerkonfigurierte Profil das Standardprofil überschreibt. Wenn in diesem Beispiel die Warteschlangen 3 und 4 nicht enthalten sind, antworten diese Warteschlangen nicht mehr auf empfangene PFC-Nachrichten.)

Denken Sie daran, dass Sie PFC auch an den Codepunkten 3, 4 und 5 in der CNP-Eingangsstanze aktivieren müssen, damit diese Konfiguration funktioniert. Wenn Sie das CNP auf einer Schnittstelle konfigurieren, wird der gesamte eingehende und ausgehende Datenverkehr blockiert, bis die Konfiguration implementiert ist, dann wird die Schnittstelle deaktiviert und der Datenverkehr wird fortgesetzt. Während der Zeit, in der die Schnittstelle blockiert wird, treten in allen Warteschlangen an der Schnittstelle Paketverluste auf.

Configuring PFC Across Layer 3 Interfaces on QFX5210, QFX5200, QFX5100, EX4600, and QFX10000 Switches

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

Unter Understanding PFC Functionality Across Layer 3 Interfaces (Verstehen der PFC-Funktionalität über Layer-3-Schnittstellen) finden Sie einen konzeptionellen Überblick darüber, wie PFC für Datenverkehr über Layer-3-Schnittstellen aktiviert werden kann. Siehe Beispiel: Konfigurieren von PFC über Layer-3-Schnittstellen als Beispiel für die Konfiguration von PFC für Datenverkehr, der Layer-3-Schnittstellen durchläuft.

Konfigurieren von DCBX (Application Protocol TLV Exchange)

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

Für jede Anwendung (z. B. iSCSI), die Für verlustfreie Übertragung konfiguriert werden soll, müssen Sie die Schnittstellen, die diesen Anwendungsdatenverkehr übertragen, aktivieren, 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 Anwendung angezeigt wird, wird die DcBX-Standardanzeige außer Kraft gesetzt, und DCBX gibt nur die konfigurierten Anwendungen an. Wenn eine Schnittstelle nur die FCoE-Anwendung anzeigen soll, müssen Sie das DCBX-Anwendungsprotokoll TLV Exchange nicht konfigurieren. Stattdessen können Sie die Standardkonfiguration verwenden.

Wenn DCBX andere Anwendungen anzeigen soll, müssen Sie eine Anwendungszuordnung explizit konfigurieren und auf die Schnittstellen anwenden, auf denen Sie Protokoll-TLVs für diese Anwendungen austauschen möchten. Wenn Sie neben anderen Anwendungsprotokoll-TLVs auch FCoE-Anwendungsprotokoll-TLVs austauschen möchten, müssen Sie die FCoE-Anwendung auch in der Anwendungszuordnung explizit konfigurieren. Verstehen von DCBX Application Protocol TLV Exchange beschreibt die Funktionsweise der Anwendungszuordnung.

Anmerkung:

Der verlustfreie Transport erfordert auch, dass Sie PFC auf der richtigen Priorität (IEEE 802.1p-Codepunkt) an den Eingangsschnittstellen mit einem Eingabe-CNP aktivieren. Wenn die an den Eingangsschnittstellen pausenbasierte Priorität 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 aktivieren, die den pausengehaltenen Eingangsprioritäten entsprechen, um mithilfe der Ausgabestanze des CNP innezuhalten.

Weitergabe des Schicksals unter den Verkehrsklassen

Sie können verschiedene verlustfreie (oder verlustfreie) Datenverkehrsströme konfigurieren, um das Schicksal zu teilen – das heißt, die gleiche CoS-Behandlung zu erhalten.

Fate Sharing ist für E/A-Konvergenz nicht wünschenswert. Anstelle der unabhängigen Kontrolle über das Schicksal jeder Art von Strömung erhalten verschiedene Arten von Strömen die gleiche Behandlung. Fate Sharing ist für verlustfreie Datenströme besonders unerwünscht. Wenn ein verlustfreier Datenfluss überlastet ist und angehalten werden muss, betrifft dies die Ströme, die das Schicksal mit dem überlasteten Fluss teilen, selbst wenn die anderen Ströme nicht überlastet sind, und auch zu Überlastungen im Hafen führen können. Wenn Ihr Netzwerk erfordert, dass alle 802.1p-Prioritäten verlustfrei sind, können Sie dies erreichen, indem Sie einigen Schicksalsausgleich zwischen den acht Prioritäten ermöglichen, indem Sie sie auf bis zu sechs verlustfreie Weiterleitungsklassen verteilen.

Wenn die Anzahl verlustfreier Prioritäten kleiner oder gleich der Anzahl konfigurierter verlustfreier Weiterleitungsklassen ist, können Sie das Teilen des Schicksals vermeiden, indem Sie eine One-to-One-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 Datenverkehrsströme so konfigurieren möchten, dass das Schicksal gemeinsam genutzt wird, werden zwei Fate-Sharing-Konfigurationen unterstützt: Zuordnung einer Weiterleitungsklasse zu mehr als einem IEEE 802.1p-Codepunkt (Priorität) und Zuordnung von zwei Weiterleitungsklassen zur gleichen Ausgabewarteschlange:

1. Wenn Sie eine verlustfreie Weiterleitungsklasse mehr als einer Priorität zuordnen, verwendet der Datenverkehr, der mit jeder der Prioritäten verschlagwortet ist, die gleichen CoS-Eigenschaften, die der Weiterleitungsklasse zugeordnet sind. Wenn Sie beispielsweise eine Weiterleitungsklasse namens fc1 konfigurieren, der Warteschlange 1 zuordnen und sie mithilfe eines Klassifizierers namens "klassifizierer1" zu Codepunkten 101 und 110 zuordnen, führt dies zu einem Datenverkehr, der mit den Prioritäten 101 und 110 verschlagwortet ist.

   Wenn in diesem Fall der Datenverkehr einer prioritätsorientierten Priorität zugeordnet wird, werden beide Prioritäten angehalten, da sie derselben Weiterleitungsklasse zugeordnet und daher ähnlich behandelt werden.

2. Wenn Sie mehrere verlustfreie Weiterleitungsklassen derselben Ausgabewarteschlange zuordnen, verwendet der den Weiterleitungsklassen zugeordnete Datenverkehr dieselbe Ausgabewarteschlange. Dies erhöht die Menge des Datenverkehrs in der Warteschlange und kann zu Überlastungen kommen, die sich auf alle Datenverkehrsflüsse auswirken, die der Warteschlange zugeordnet werden. Wenn beispielsweise zwei Weiterleitungsklassen namens fc1 und fc2 konfiguriert werden, indem beide Weiterleitungsklassen der Warteschlange 1 zugeordnet und die Weiterleitungsklassen an die Codepunkte 101 und 110 (jeweils) mit einem Klassifizierer namens classify1 zugeordnet werden, führt der Datenverkehr mit den Prioritäten 101 und 110, die das Schicksal in derselben Ausgabewarteschlange teilen:

   In diesem Fall verwenden die beiden Weiterleitungsklassen zwar unterschiedliche IEEE 802.1p-Prioritäten, aber wenn eine Weiterleitungsklasse überlastungsbereit ist, wirkt sie sich auf die andere Weiterleitungsklasse aus. Der Grund dafür ist, dass der gesamte Datenverkehr, der diese Warteschlange verwendet, angehalten wird, wenn die Ausgabewarteschlange wegen Engpässen in der Weiterleitungsklasse angehalten wird. Da beide Weiterleitungsklassen der Warteschlange zugeordnet werden, wird der Datenverkehr, der beiden Weiterleitungsklassen zugeordnet ist, angehalten.

   Anmerkung:

   Wenn Sie einer Warteschlange mehr als eine Weiterleitungsklasse zuordnen, müssen alle derselben Warteschlange zugeordneten Weiterleitungsklassen das gleiche Packet Drop-Attribut haben (alle Weiterleitungsklassen müssen verlustfrei sein, oder alle Weiterleitungsklassen, die einer Warteschlange zugeordnet werden, 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 weiterleitet (oder anderen Datenverkehr, der einen verlustfreien Transport über das Ethernet-Netzwerk erfordert), wird die Konfiguration von Klassifizierern, verlustfreien Weiterleitungsklassen, DCBX und PFC an Eingangs- und Ausgangsschnittstellen zur Unterstützung verlustfreier Übertragung wie in diesem Dokument beschrieben.

Wenn ein Switch als FCoE-FC-Gateway fungiert (wenn native FC-Schnittstellen auf Ihrem Switch unterstützt werden), verwendet das System native FC-Schnittstellen (NP_Ports), um eine Verbindung zum FC-Switch (oder FCoE-Forwarder) am FC-Netzwerk-Edge herzustellen. Sie können CNPs oder DCBX nicht auf native FC-Schnittstellen anwenden, nur auf Ethernet-Schnittstellen.

In einem FCoE-FC-Gateway entspricht die Ethernet-Schnittstellenkonfiguration von Klassifizierern, DCBX und PFC der Ethernet-Schnittstellenkonfiguration auf einem Transit-Switch. Die Konfiguration verlustfreier Weiterleitungsklassen ist ebenfalls gleich.

Die Unterstützung verlustfreier Übertragung 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.

Standardmäßig kennzeichnen native FC-Schnittstellen Pakete mit Priorität 3, wenn sie eingehende FC-Pakete in Ethernet verkapseln. Wenn Ihr FCoE-Netzwerk für FCoE-Datenverkehr eine andere Priorität als 3 verwendet, müssen Sie den Prioritätswert auf den Wert neu schreiben, den Ihr Netzwerk auf der FC-Schnittstelle verwendet, den FCoE-Datenverkehr auf die richtige Priorität an den Ethernet-Schnittstellen klassifizieren und PFC auf der richtigen Priorität an den Ethernet-Schnittstellen aktivieren, wie in Understanding CoS IEEE 802.1p Priority Remapping on an FCoE-FC Gateway beschrieben.

Konfigurationsergebnisse und Commit-Prüfungen

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

Tabelle 5 beschreibt jeweils die Ergebnisse der möglichen verlustfreien Übertragungskonfigurationen. In der Spalte Result wird angenommen, dass die Puffer-Kopfraumberechnung des Systems zu einer erfolgreichen Konfiguration geführt hat.

Wenn das System jedoch berechnet, dass der Pufferspeicher zur Unterstützung der Konfiguration nicht ausreicht, wird durch eine Commit-Prüfung verhindert, dass Sie die Konfiguration auf einer einzelnen Ethernet-Schnittstelle committen. Bei LAG-Schnittstellen gibt das System keinen Commit-Prüffehler aus, sondern eine syslog-Meldung.

Anmerkung:

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

Anmerkung:

Wenn Sie versuchen, SOWOHL PFC als auch Ethernet PAUSE auf einer Verbindung zu konfigurieren, gibt das System einen Commit-Fehler zurück. PFC und Ethernet PAUSE schließen Konfigurationen auf einer Schnittstelle gegenseitig aus.