Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Grundlegendes zu FCoE

Fibre Channel over Ethernet (FCoE) ist eine Methode zur Unterstützung konvergierter Fibre Channel (FC) und Ethernet-Datenverkehr in einem Datencenter-Bridging -Netzwerk (DCB). FCoE verkapselt unveränderte FC-Frames in Ethernet, um die FC-Frames über ein physisches Ethernet-Netzwerk zu transportieren. Das T11 Technical Committee, das für FC-Schnittstellen zuständige Komitee des International Committee for Information Technology Standards (INCITS) ist, hat den FCoE-Standard entwickelt, um eine Methode für den Transport von FC-Frames über ein DCB-Netzwerk bereitzustellen. Das T11-Dokument Fibre Channel Backbone - 5 (FC-BB-5) Rev 2.00 bei http://www.t11.org/ftp/t11/pub/fc/bb-5/09-056v5.pdf enthält Details zum FCoE-Standard Version 1.

Hinweis:

Der Switch unterstützt das T11 Annex F FCoE Pre-FIP Virtual Link Instantiation Protocol nicht.

Für das Ethernet-Netzwerk ist ein FCoE-Frame der gleiche wie jeder andere Ethernet-Frame, da die Ethernet-Kapselung die Header-Informationen bereitstellt, die für die Weiterleitung der Frames benötigt werden. Um jedoch das verlustfreie Verhalten zu erreichen, das der FC-Transport erfordert, muss das Ethernet-Netzwerk den DCB-Standards entsprechen.

DCB-Standards schaffen eine Umgebung, in der FCoE nativen FC-Datenverkehr mit Ethernet-Kapselung übertragen kann, während gleichzeitig der obligatorische Class of Service (CoS) und andere Merkmale, die FC-Datenverkehr erfordert, beibehalten werden.

Die Unterstützung von FCoE in einem DCB-Netzwerk erfordert, dass die FCoE-Geräte im Ethernet-Netzwerk und die FC-Switches am Edge des SAN-Netzwerks sowohl Ethernet als auch nativen FC-Datenverkehr verarbeiten. Um Ethernet-Datenverkehr zu bewältigen, kann ein FC-Switch eines von zwei Dingen:

  • Integriert FCoE-Schnittstellen.

  • Verwendet ein FCoE-FC-Gateway wie einen QFX3500-Switch, um FCoE-Datenverkehr von FCoE-Geräten in native FC zu entkapseln und nativen FC-Datenverkehr vom FC-Switch in FCoE zu verkapseln und über das Ethernet-Netzwerk an FCoE-Geräte weiterzuleiten.

Hinweis:

Eigenständige Switches unterstützen FCoE. Virtual Chassis (VC) und Virtual Chassis Fabric (VCF) im gemischten Modus unterstützen FCoE nicht. Reine QFX5100-Switch-VCFs (bestehend aus nur QFX5100-Switches) unterstützen FCoE.

FCoE-Konzepte umfassen:

FCoE-Geräte

Jedes FCoE-Gerät verfügt über einen konvergierten Netzwerkadapter (CNA), der die Funktionen eines FC Host Bus Adapter (HBA) und einer verlustfreien Ethernet-Netzwerkschnittstellenkarte (NIC) mit 10-Gbit/s Ethernet-Ports kombiniert. Der Teil des CNA, der FCoE-Datenverkehr verwaltet, wird als FCoE-Knoten (ENode) bezeichnet. Ein ENode kombiniert FCoE-Terminierungsfunktionen mit dem Client-Teil des FC-Stacks auf dem CNA.

ENodes stellen virtuelle FC-Schnittstellen zu FC-Switches in Form von virtuellem N_Ports (VN_Ports) dar. Ein VN_Port ist ein Endpunkt in einer virtuellen Punkt-zu-Punkt-Verbindung, die als virtuelle Verbindung bezeichnet wird. Das andere Endgerät der virtuellen Verbindung ist ein FC-Switch (oder FCF)-Port. Ein VN_Port emuliert eine native FC-N_Port und führt ähnliche Funktionen aus: die Erstellung, Erkennung und den Fluss von Nachrichten an und vom FC-Switch. Ein einzelner ENode kann mehrere VN_Ports hosten. Jede VN_Port verfügt über einen separaten, einzigartigen virtuellen Link mit einem FC-Switch.

ENodes enthalten mindestens einen verlustfreien Ethernet Media Access Controller (MAC). Jeder Ethernet-MAC wird mit einem FCoE-Controller gekoppelt. Der verlustfreie Ethernet-MAC ist ein Vollduplex-Ethernet-MAC, der Ethernet-Erweiterungen implementiert, um Frameverluste aufgrund von Überlastung zu vermeiden und Frames von mindestens 2500 Bytes unterstützt. Der FCoE-Controller instanziiert und beendet VN_Port Instanzen dynamisch, wie sie für FCoE-Sitzungen benötigt werden. Jede VN_Port Instanz verfügt über eine eigene virtuelle Verbindung zu einem FC-Switch.

Hinweis:

Eine Sitzung ist eine Fabric-Anmeldung (FLOGI) oder eine Fabric Discovery (FDISC)-Anmeldung bei der FC SAN-Fabric. Sitzung bezieht sich nicht auf End-to-End-Server-to-Storage-Sitzungen.

ENodes enthalten außerdem einen FCoE Link End Point (LEP) für jede VN_Port Verbindung. Ein FCoE LEP ist eine virtuelle FC-Schnittstelle, die auf der physischen Ethernet-Schnittstelle abgebildet ist.

Ein FCoE LEP:

  • Übermittelt und empfängt FCoE-Frames auf dem virtuellen Link.

  • Ermöglicht die FC-Frame-Kapselung für Den Datenverkehr, der vom Server zum FC-Switch geht.

  • Führt eine Frame-Entkapselung des vom FC-Switch empfangenen Datenverkehrs durch.

Abbildung 1 zeigt ein Blockdiagramm der wichtigsten ENode-Komponenten.

Abbildung 1: ENode-Komponenten ENode Components

FCoE-Rahmen

Die FCoE-Protokollspezifikation ersetzt die FC0- und FC1-Schichten des FC-Stacks durch Ethernet, behält aber den FC-Frame-Header bei. Wenn der FC-Frame-Header beibehalten wird, kann der FC-Frame nach der Entkapselung direkt an ein natives FC SAN übergeben werden. Der FCoE-Header enthält die FC Start of File (SOF)-Bits und End of File (EOF)-Bits in einem kodierten Format. FCoE unterstützt zwei Frametypen, Control Frames und Datenrahmen. Das FCoE Initialization Protocol (FIP) enthält alle Erkennungs- und Fabric-Anmelderahmen.

FIP-Steuerungsframes übernehmen die Erkennung von FCoE-Geräten, initialisieren die Kommunikation und pflegen die Kommunikation. Sie transportieren keine Datennutzlast. FIP verfügt über einen eigenen EtherType (0x8914), um FIP-Datenverkehr vom FCoE- und anderen Ethernet-Datenverkehr zu unterscheiden. Zum Aufbau der Kommunikation verwendet der ENode die vom CNA-Hersteller zugewiesene global eindeutige MAC-Adresse.

Nachdem FIP eine Verbindung zwischen FCoE-Geräten hergestellt hat, übernehmen die FCoE-Datenrahmen den Transport der in Ethernet gekapselten FC-Frames. FCoE verfügt auch über einen eigenen EtherType (0x8906), um FCoE-Frames von anderen Ethernet-Datenverkehr zu unterscheiden und die in-order Frame-Handhabung zu gewährleisten, die FC erfordert. FCoE-Rahmen umfassen:

  • 2112 Bytes FC-Nutzdaten

  • 24 Bytes FC-Header

  • Standard-Ethernet-Header mit 14 Bytes

  • 14 Bytes FCoE-Header

  • 8 Byte zyklische Redundanzprüfung (CRC) plus EOF

  • 4 Bytes VLAN-Header

  • 4 Byte Frame Check Sequence (FCS)

Die Nutzdaten, Header und Überprüfungen summieren bis zu 2180 Bytes. Daher sollten Schnittstellen, die FCoE-Datenverkehr übertragen, eine konfigurierte maximale Übertragungseinheit (MTU) von 2180 oder höher haben. Eine MTU-Größe von 2180 Bytes ist die Mindestgröße; einige Netzwerkadministratoren bevorzugen eine MTU mit 2240 oder 2500 Bytes.

Virtuelle Links

Native FC verwendet Punkt-zu-Punkt-physische Verbindungen zwischen FC-Geräten. In FCoE ersetzen virtuelle Verbindungen die physischen Verbindungen. Eine virtuelle Verbindung emuliert eine Punkt-zu-Punkt-Verbindung zwischen zwei FCoE-Geräteendpunkten, z. B. einem Server-VN_Port und einem FC-Switch (oder FCF) VF_Port.

Jede FCoE-Schnittstelle kann mehrere virtuelle Verbindungen unterstützen. Die MAC-Adressen der FCoE-Endgeräte (der VN_Port und der VF_Port) identifizieren jeden virtuellen Link eindeutig und ermöglichen den Datenverkehr für mehrere virtuelle Verbindungen, um dieselbe physische Verbindung zu teilen, während gleichzeitig die Trennung und Sicherheit der Daten gewahrt bleibt.

Ein virtueller Link ist in einem FCoE-VLAN vorhanden und darf nicht zu mehr als einem VLAN gehören. Obwohl der FC-Switch und das FCoE-Gerät eine virtuelle Verbindung als Punkt-zu-Punkt-Verbindung erkennen, müssen virtuelle Verbindungen nicht direkte Verbindungen zwischen einem VF_Port und einem VN_Port sein. Eine virtuelle Verbindung kann einen oder mehrere Transit-Switches passieren, die auch als Passthrough-Switches bezeichnet werden. Ein Transit-Switch kann virtuelle Verbindungen transparent aggregieren, während sie weiterhin angezeigt werden und als Punkt-zu-Punkt-Verbindung zu den FCoE-Geräten funktionieren. Ein virtueller Link muss jedoch innerhalb einer einzigen Layer-2-Domain verbleiben.

FCoE-VLANs

Der gesamte FCoE-Datenverkehr muss in einem VLAN übertragen werden, das nur FCoE-Datenverkehr transportiert. Nur FCoE-Schnittstellen sollten Mitglieder eines FCoE-VLANs sein. Ethernet-Datenverkehr, der nicht FCoE- oder FIP-Datenverkehr ist, muss in einem anderen VLAN übertragen werden.

Hinweis:

Auf einem eigenständigen Switch oder einem QFabric-System-Node-Gerät kann dasselbe VLAN nicht sowohl im Transit-Switch-Modus als auch im FCoE-FC-Gateway-Modus verwendet werden.

Hinweis:

FCoE-VLANs (alle VLANs, die FCoE-Datenverkehr übertragen) unterstützen nur Spanning Tree Protocol (STP) und Link Aggregation Group (LAG) Layer 2-Funktionen.

FCoE-Datenverkehr kann eine Standard-LAG nicht verwenden, da der Datenverkehr bei verschiedenen Übertragungen an unterschiedliche physische LAG-Links hasht wird. Dadurch wird der (virtuelle) Punkt-zu-Punkt-Link unterbrochen, den Fibre Channel-Datenverkehr benötigt. Wenn Sie eine Standard-LAG-Schnittstelle für FCoE-Datenverkehr konfigurieren, wird FCoE-Datenverkehr möglicherweise vom FC SAN abgelehnt.

QFabric-Systeme unterstützen eine spezielle LAG namens FCoE LAG, die es Ihnen ermöglicht, FCoE-Datenverkehr und regelmäßigen Ethernet-Datenverkehr (Datenverkehr, der nicht FCoE-Datenverkehr ist) über dasselbe Link Aggregationspaket zu übertragen. Standard-LAGs verwenden einen Hashing-Algorithmus, um zu bestimmen, welche physische Verbindung in der LAG für eine Übertragung verwendet wird. Daher kann die Kommunikation zwischen zwei Geräten unterschiedliche physische Verbindungen in der LAG für unterschiedliche Übertragungen verwenden. Eine FCoE-LAG stellt sicher, dass FCoE-Datenverkehr dieselbe physische Verbindung in der LAG für Anfragen und Antworten verwendet, um die virtuelle Punkt-zu-Punkt-Verbindung zwischen dem FCoE-gerätekonvergierten Netzwerkadapter (CNA) und dem FC SAN-Switch auf dem QFabric-Systemknotengerät beizubehalten. Eine FCoE-LAG bietet keine Load Balancing oder Link-Redundanz für FCoE-Datenverkehr. Regelmäßiger Ethernet-Datenverkehr verwendet jedoch den Standard-Hashing-Algorithmus und erhält die üblichen LAG-Vorteile von Load Balancing und Link-Redundanz in einer FCoE-LAG.

Hinweis:

IGMP-Snooping ist standardmäßig auf allen VLANs in allen Softwareversionen vor Junos OS R13.2 aktiviert. Deaktivieren Sie IGMP-Snooping auf FCoE-VLANs, wenn Sie Software verwenden, die älter als 13.2 ist.

Sie können mehr als ein FCoE-VLAN konfigurieren, aber jeder bestimmte virtuelle Link muss sich in nur einem FCoE-VLAN sein.

Hinweis:

Alle 10-Gigabit-Ethernet-Schnittstellen, die eine Verbindung zu FCoE-Geräten herstellen, müssen ein natives VLAN konfiguriert sein, um FIP-Datenverkehr zu übertragen, da FIP VLAN-Erkennungs- und Benachrichtigungs-Frames als nicht getaggte Pakete ausgetauscht werden.

Auf Switches, die die ENHANCED Layer 2 Software (ELS) CLI verwenden, reicht es nicht aus, das native VLAN auf der Schnittstelle zu konfigurieren, die Schnittstelle muss auch als Mitglied des nativen VLANs konfiguriert werden. (Dies liegt daran, dass die ELS-CLI den Modus für getaggten Zugriff nicht unterstützt, sodass Schnittstellen, die Mitglieder von FCoE-VLANs sind, den Trunk-Modus verwenden müssen, und Trunk-Port-Schnittstellen müssen explizit als Mitglieder eines nativen VLANs einbezogen werden.)

Darüber hinaus muss die VLAN-ID mit der nativen VLAN-ID übereinstimmen, die Sie auf der physischen Schnittstelle konfigurieren. Um beispielsweise ein natives VLAN mit der ID auf der 20 Schnittstelle xe-0/0/15 zu konfigurieren, die Mitglied eines FCoE-VLANs ist, müssen Sie die folgenden Anweisungen in die Konfiguration aufnehmen:

  1. Konfigurieren Sie das native VLAN auf der Schnittstelle:

    (Die entsprechende Konfigurationsaussage auf einem Nicht-ELS-Geräte-Switch wäre set interfaces xe-0/0/15 unit 0 family ethernet-switching native-vlan-id 20.)

  2. Konfigurieren Sie den Port als Mitglied des nativen VLANs (dieser Schritt ist auf Switches, die die ELS-Software nicht verwenden, nicht erforderlich):

Best Practices:

Nur FCoE-Datenverkehr ist auf dem FCoE-VLAN zulässig. Ein natives VLAN muss möglicherweise nicht getaggten Datenverkehr verschiedener Arten und Protokolle übertragen. Daher ist es sinnvoll, das native VLAN von FCoE-VLANs getrennt zu halten.