Die (R)Evolution der Rechenzentren; Teil 38

FC-BB_E im Detail – Die Steuerprotokolle im Detail

29.04.2011 | Autor / Redakteur: Dr. Franz-Joachim Kauffels / Andreas Donner

Konvergente Rechenzentrumsnetze können – müssen aber nicht – auf optischen Übertragungswegen aufsetzen.
Konvergente Rechenzentrumsnetze können – müssen aber nicht – auf optischen Übertragungswegen aufsetzen.

Schon in den letzten zwei Folgen haben wir Aufbau, Funktionen und Möglichkeiten von FC-BB_E näher betrachtet und entsprechende Schlüsse gezogen. Das Verständnis von FC-BB_E ist wesentlich für sichere Entscheidungen bei Planung, Konfiguration und Aufbau konvergierter RZ-Netze. Die Steuerprotokolle weisen eine Reihe von interessanten Einzelheiten auf, die ich hier informell zusammenfassen möchte, sofern sie dem Gesamtverständnis dienlich sind.

Das FCoE Initialization Protokoll FIP muss FC-BB_E-Geräte erkennen, initialisieren und warten. Dafür werden eine Reihe enkapsulierter FIP-Operationen spezifiziert. FIP-Operationen und dazu gehörige Kontrollframes werden dazu benutzt, folgende Funktionen auszuführen:

  • FIP VLAN Discovery
  • FIP Discovery
  • FCoE Virtual Link Initialisierung (und Schaffung der betreffenden Instanzen)
  • FCoE Virtual Link Wartung

Alle FIP-Protokolle laufen auf einer per-VLAN-Basis. Es wird empfohlen, auf dem default VLAN nach IEEE 802.1Q zuerst das FIP VLAN Discovery Protokoll laufen zu lassen. Alle anderen FIP-Protokolle laufen in denjenigen VLANs, die die FC-BB_E-Services bereitstellen.

Die Unterstützung multipler Fabrics im Rahmen eines einzelnen VLANs ist außerhalb der Betrachtung des Standards. Der Grund dafür ist, dass die im Standard beschriebenen Sicherheitsmaßnahmen nicht auseichen, um dauerhaft zu garantieren, dass die FCoE Frames immer an die richtige Fabric geschickt werden, wenn es mehrere gibt. Auf ENodes muss die ENode MAC-Adresse für alle FIP-Frames mit Ausnahme des Keep Alive Frames benutzt werden, bei FCFs kann die MAC-Adresse für alle FIP-Frames gebraucht werden. Kommen zufällig FIP-Frames mit der falschen MAC-Adresse an, müssen sie verworfen werden.

Bestandsaufnahme

Zu Beginn der Arbeit kann eine ENode-MAC oder eine FCF-MAC das FIP-VLAN-Discovery Protokoll dazu benutzen, um festzustellen, welche VLANs im Lossless Ethernet FC-BB_E-Dienste unterstützen. Das kann wegfallen, wenn die VLANs schon bekannt sind oder es keine gibt. Das Verfahren funktioniert mit Multicast VLAN-Requests und entsprechenden Unicast-Antworten. Es arbeitet vollständig deterministisch.

Sobald das VLAN Discovery Programm gelaufen ist, sind die VLANs bekannt und das FIP Discovery Protokoll kann laufen. Es wird von den FCFs initialisiert und fragt alle ENode-MAC Gruppenadressen per periodischem Multicast ab, ob sie noch da sind, um es einfach zu formulieren. Außerdem ermöglicht es ENodes, die grade anfangen, die Aufnahme in das Kommunikationssystem. Zudem gibt es eine Variante dieses Protokolls, die dafür zuständig ist, nachzusehen, ob auch noch alle FCFs da sind. Diese läuft dann auf allen FCFs gegenseitig ab. Dabei gibt es ein zufällig gewähltes Delay von Null bis 100 ms, welches vermeiden soll, dass im zugrunde liegenden Lossless Ethernet durch zu viele Multicast-Nachrichten Synchronisations-Bursts entstehen, die letztlich den Gesamtverkehr irritieren.

Im Standard wird detailliert beschrieben, wie die Verfahren arbeiten. Das wollen wir hier nicht weiter vertiefen. Insgesamt ist es aber so, dass auch viele weitere Kontrollnachrichten verwertet werden, die im Rahmen des laufenden Betriebs entstehen. Alle diese Programme arbeiten streng deterministisch und führen in jedem Fall zu einem definierten Ergebnis.

Das Initialisierungsprogramm ist weiter nicht spannend. Es initialisiert virtuelle Verbindungen in der bereits weiter oben insgesamt beschriebenen Art und Weise.

Richtig wichtig ist das Wartungs-Programm. Es beschreibt nämlich, wie man mit Fehlern umgeht, die im zugrundeliegenden Ethernet auftreten können. Sobald eine ENode-MAC irgendwelche Fehler entdeckt, löst sie alle Instanzen für die virtuellen Links zwischen VN_Ports und VF_Ports auf. Für die betroffenen VN_Ports sieht das wie ein impliziter Fabric Logout aus. Die ENode-MAC kann die Instanzen ja wieder erwecken, wenn sie sieht, dass alles wieder richtig läuft. Um auch nicht-lokale Fehler auf diese Weise behandeln zu können, müssen die FCoE-Controller auf den ENode-MACs und den FCF-MACs periodisch Nachrichten austauschen, die den Zustand der jeweils entfernten Geräte und Schnittstellen beschreiben. Wenn ein Administrator das unbedingt möchte, kann er diese Funktionen auch ausschalten.

weiter mit: Kontrollnachrichten & Keep Alive Frames

 

ComConsult Rechenzentrum Infrastruktur-Redesign Forum 2011

Inhalt des Artikels:

Kommentare werden geladen....

Was meinen Sie zu diesem Thema?

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 2050953 / Grundlagen)