Benutzer:Geroll/FIP

Dieser Artikel ist im Entstehen und noch nicht Bestandteil der freien Enzyklopädie Wikipedia.

Solltest du über eine Suchmaschine darauf gestoßen sein, bedenke, dass der Text noch unvollständig sein und Fehler oder ungeprüfte Aussagen enthalten kann. Wenn du Fragen zum Thema hast, nimm Kontakt mit dem Autor Geroll auf.

Das FCoE intitialization Protocol (FIP) ist eines von zwei Protokollen des Fibre-Channel-Over-Ethernet-Standards (FCoE). Da Fibrechannel selber sehr hohe Anforderungen an den Transport seiner Daten stellt wird die Steuerung und Sicherung der Transportverbindung über Ethernet durch ein unabhängig Protokoll gewährleistet (FIP) während die Daten selber via FCoE transportiert werden. Eine wesentliche Aufgabe des FCoE Initialization Protokolls ist beipielsweise das Login und Logout der Fibrechannel-Komponenten innerhalb eines FCoE-Netzwerks.

Anwendung und Motivation

FCoE Initialization Protocol (FIP) ist das FCoE Kontrollprotokoll und damit verantwortlich für den Aufbau und die Kontrolle von FC Virtual Linls zwischen zwei FCoE Teilnehmern.

Während der Phase des Linkaufbaus erkundet FIP FCoE VLANs und virtuelle FC-Interfaces. Nach diesem Discovery-Prozess führt FIP virtual link Intialisierungsfunktionen durch (fabric login, fabric discovery u.Ä.). Nachdem ein virtueller Link hergestellt werden konnte, kann der Datentransfer mit Hilfe der Original FC-Payload über den Link erfolgen. Während dieser FC-Operationen bleibt FIP im Hintergrund und dient im Wesentlichen zur Pflege des virtuellen Links. So werden reglmässig Wartungsoperationen durchgeführt, um die Erreichbarkeit der zwischen den virtuellen FC-Interfaces zu prüfen.

Fibre Channel over Ethernet (FCoE) ist ein Protokoll zur Übertragung von Fibre-Channel-Rahmen in Vollduplex-Ethernet-basierten Netzwerken. Das wesentliche Ziel bei der Einführung von FCoE dient der I/O-Konsolidierung auf der Basis von Ethernet (IEEE 802.3) im Hinblick auf die Reduktion physischer Komplexität von Netzwerkstrukturen besonders in Rechenzentren.

Funktionalität

FIP dient der Etablierung von virtuellen FC links zwischen sogenannten VN_Ports (ENode to FC) und VE_Ports (FCF to FCF), der Pflege der virtuellen Links und bietet Primitiven zum Abbau des Links in Folge administrativer Eingriffe an.

Die Standardisierung von FCoE begann im April 2007 innerhalb der FC-BB-5-Arbeitsgruppe der T11 und wurde am 4. Juni 2009 der INCITS zur Publikation als FC-BB-5-Draft-Standard übergeben.

Discovery and Virtual Link Establishment

FIP implementiert zwei wesentliche Discovery-Protokolle und ein Protokoll zur Herstellung virtueller Links zwischen VN_Ports und VF_Ports. Typischerweise werden diese Protokolle von ENodes initiiert, obgleich auch FCFs unaufgefordert FIP Advertisements generieren können.

Figure 4. FIP Virtual Link Establishment All the protocols are usually initiated by ENodes, although FCFs can generate unsolicited FIP advertisements, as discussed later in this section. Note that the FIP frames at the top and the FCoE frames at the bottom of Figure 4 use different EtherTypes and encapsulations, since the FCoE frames encapsulate native Fibre Channel payloads, whereas FIP frames describe a new set of protocols that have no reason to exist in native Fibre Channel definitions. Among the differences, note that ENodes use different source MAC addresses for FIP and FCoE encapsulation. FIP packets are built using a globally unique MAC address assigned to the CNA at manufacturing (called the ENode MAC address), whereas FCoE packets are encapsulated using a locally unique MAC address (that is, unique only within the boundaries of the local Ethernet subnet) dynamically assigned to the ENode by the FCF as part of the FIP virtual link establishment process (a fabric-provided MAC address [FPMA]). The definition of the FPMA is shown in Figure 5.

Figure 5. FPMA FPMAs use the 24-bit-wide Fibre Channel ID (FC_ID) assigned to the CNA during the FIP FLOGI and FDISC exchange, and therefore they cannot be available to the CNA before the fabric login has occurred. The FPMA is built by appending the FC_ID to a 24-bit quantity called the FCoE MAC address prefix (FC-MAP). FC-BB-5 defined a range of 256 FC-MAPs to facilitate FCoE deployments. Cisco has established very simple best practices (see "FCoE VLANs" earlier in this document) that make the manipulation of FC-MAPs unnecessary, and most users should find the default FC-MAP value 0E-FC-00 sufficient. The 256 different FC-MAPs make available to users up to 256 pools of locally unique MAC addresses. The pools are useful when the FC_IDs are not unique on an Ethernet VLAN; for instance, when different Fibre Channel fabrics or different VSANs are encapsulated in the same Ethernet VLAN, the ranges of FC_IDs assigned in each Fibre Channel fabric may overlap. Cisco strongly recommends that you never attempt to map multiple Fibre Channel fabrics onto the same Ethernet VLAN. Most users will not ever need to map multiple Fibre Channel fabrics onto the same physical Ethernet network, but if such a need arises, each Fibre Channel fabric should be encapsulated in a separate VLAN.

FIP VLAN Discovery

FIP VLAN discovery discovers the FCoE VLAN that will be used by all other FIP protocols as well as by the FCoE encapsulation for Fibre Channel payloads on the established virtual link. One of the goals of FC-BB-5 was to be as nonintrusive as possible on initiators and targets, and therefore FIP VLAN discovery occurs in the native VLAN used by the initiator or target to exchange Ethernet traffic. The FIP VLAN discovery protocol is the only FIP protocol running on the native VLAN; all other FIP protocols run on the discovered FCoE VLANs. The ENode sends a FIP VLAN discovery request to a multicast MAC address called All-FCF-MACs, which is a multicast MAC address to which all FCFs listen. All FCFs that can be reached in the native VLAN of the ENode are expected to respond on the same VLAN with a response that lists one or more FCoE VLANs that are available for the ENode's VN_Port login. This protocol has the sole purpose of allowing the ENode to discover all the available FCoE VLANs, and it does not cause the ENode to select an FCF. FIP VLAN discovery is an optional protocol in FC-BB-5. An ENode implementation can choose to offer only manual configuration for FCoE VLANs, and therefore choose not to perform FIP VLAN discovery. It is commonly assumed that such implementation will default to VLAN 1002 for its FCoE VLAN. The Cisco Nexus 5000 Series supports FIP VLAN discovery, and it will respond to any ENode that performs a query. The contents of the response depend on how the virtual FC interface is configured on the Cisco Nexus 5000 Series Switch, as discussed later in this document.

FIP FCF Discovery

FIP FCF discovery is the protocol used by ENodes to discover FCFs that can accept logins. FCFs periodically send FIP FCF discovery advertisement messages on each configured FCoE VLAN; these messages are destined for the multicast MAC address All-ENode-MACs, a multicast MAC address to which all ENodes listen. The FIP FCF discovery advertisement is used by the FCF to inform any potential ENode in the VLAN that FCF VF_Ports are available for virtual link establishment with ENodes' VN_Ports. The advertisement includes the MAC address of the FCF as well as other parameters useful for tuning the characteristics of the virtual link (FIP timeout values, FCF priority, etc.). Given the periodic nature of the advertisements, new ENodes joining the network will typically not want to wait to collect multicast FIP FCF discovery advertisements from all FCFs, and therefore FC-BB-5 allows ENodes to solicit unicast advertisements by sending a FIP FCF discovery solicitation to the All-FCF-MACs multicast MAC address. FCFs receiving the solicitation can generate a unicast FIP FCF discovery advertisement addressed to the requesting ENode. Upon collection of these advertisements, the ENode can make the final decision as to which FCF to contact for the establishment of a virtual link with its VN_Port.

FIP FLOGI and FDISC

After the ENode has discovered all FCFs and selected one for login, the last step is to inform the selected FCF of the intention to create a virtual link with its VF_Port. After this step, Fibre Channel payloads (encapsulated in FCoE frames) can start being exchanged on the new virtual link just established. On any native Fibre Channel link between an N_Port and an F_Port, the first protocol exchange performed as part of activating the data-link layer is the fabric login, or FLOGI, which results in the assignment of an FC_ID to the N_Port. In designing FIP, the T11 committee decided to merge the logical step of FCF selection by an ENode in FIP with the native Fibre Channel fabric login exchange. The result of this optimization is a single FIP exchange that serves both purposes of FCF selection, as well as fabric login and FC_ID allocation. This optimization is not only convenient; it is a requirement for obtaining an appropriate FPMA for the ENode to use in the subsequent FCoE encapsulated frames. FIP FLOGI and FDISC are unicast frames almost identical to the native Fibre Channel FLOGI and FDISC frames they replace. The VN_Port sends an FLOGI or an FDISC request, followed by the corresponding FLOGI or FDISC accept payload from the FCF. Completion of this exchange terminates the FIP virtual link establishment phase.

FCoE Security Model

Direct-Attach FCoE When an ENode is directly attached to an FCF, the FIP virtual link establishment described previously is a set of point-to-point exchanges that map one or more virtual links on top of a physical Ethernet link (Figure 6). In this simple scenario, a Fibre Channel stack exists at both ends of the physical wire. Although on the physical wire (at Layer 1) all packets are encoded using Ethernet encodings, the Fibre Channel stack assumes the responsibility of forwarding FCoE frames as if they were native Fibre Channel frames.

Figure 6. Direct-Attach Connection Between ENodes and FCFs In the direct-attach model, Fibre Channel semantics apply fully to all FCoE frames from the data-link layer up. Forwarding, management, troubleshooting, link events: everything looks exactly alike between a native Fibre Channel physical link and a virtual link using FCoE. Obviously, this approach implies that even from a security perspective, FCoE does not inherently add any more risk than a native Fibre Channel segment in a Fibre Channel fabric. This property of direct-attach FCoE makes the direct-attach model highly desirable, since it offers SAN administrators the opportunity to start using FCoE without really having to go beyond their domain of expertise. In a way, even FIP can be seen as just a formality in this context, and first-generation CNAs prove this point, since first-generation CNAs do not support FIP but nonetheless enable FCoE in direct-attach topologies.

Remote-Attach FCoE If direct-attach FCoE topologies are the most desirable way to enable FCoE, why would anyone ever want to use another approach? The quick answer is complexity: switches with FCF capabilities are more complex for vendors to implement than regular Ethernet switches, and therefore in certain contexts users will face a trade-off between the convenience of a direct-attach model and the lack of a strong portfolio of FCF offerings to meet their needs. One typical scenario that is often cited is that of blade switches. A blade switch is typically a simpler device than a traditional access-layer switch, and time-to-market or return-on-investment (ROI) concerns may cause blade switch vendors to choose to have their Ethernet blade switches behave as FCoE passthrough switches, rather than implement a full FCF. Under those conditions, users have no choice but to forego direct-attach FCoE and use remote-attach FCoE solutions. In a remote-attach FCoE solution, the virtual link established between a VN_Port and a VF_Port maps to an Ethernet path that includes one or more FCoE passthrough switches (Figure 7). Each FCoE passthrough switch does not have a Fibre Channel stack and therefore makes forwarding decisions based purely on Ethernet semantics. This type of environment is where FIP adds the most value to the FCoE solution.

Figure 7. Remote-Attach Connection Between ENodes and FCFs Obviously, if a virtual link is built on top of one or more Ethernet devices that are transparent to the Fibre Channel fabric, the native Fibre Channel security model will not be sufficient to address security concerns on those devices. For this reason, FC-BB-5 includes an informative addition, Annex D, to offer a solution to the potential Fibre Channel security threats on FCoE passthrough switches. Implementation of the recommendations in FC-BB-5 (Recommendation D.4.1, which is more stringent, and Recommendation D.4.2, which is less stringent) is optional for vendors providing FCoE passthrough switches. Absence of these functions in an FCoE passthrough switch does not necessarily make FCoE undeployable, but it leaves the deployment susceptible to the security threats described in Annex D of FC-BB-5. Some administrators may not find these threats applicable to their environments and so choose to deploy FCoE passthrough switches that do not offer these functions (or choose to keep them disabled), but Cisco recommends enabling these functions whenever possible. Since for the foreseeable future the Cisco Nexus 5000 Series is expected to be deployed as an FCF and not as an FCoE passthrough switch, these recommendations are not available on the Cisco Nexus 5000 Series as of Cisco NX-OS Software Release 4.1(3)N1(1).

FIP Snooping In the industry, FCoE passthrough switches that implement either Recommendation D.4.1 or D.4.2 are commonly referred to as FIP snooping switches, to distinguish them from FCoE passthrough switches that simply implement IEEE DCB and do not offer any additional FCoE security capability on top of that. The term "FIP snooping" is not defined in FC-BB-5, and it is slightly misleading, since under certain conditions Recommendation D.4.1 or D.4.2 could be implemented without snooping any packet. This document avoids use of this definition, but it is reported here for completeness.

Cisco Nexus 5000 Series Virtual Fibre Channel Interfaces The Cisco Nexus 5000 Series software uses the virtual Fibre Channel interface construct to infer the number of VF_Ports that need to be exposed by FIP in each FCoE VLAN. Like any interface in Cisco NX-OS, virtual FC interfaces (called vfc in the CLI) are manipulable objects with properties such as configuration and state. Virtual FC interfaces behave like native Fibre Channel interfaces, except for the lack of VE_port capabilities as of Cisco NX-OS Software Release 4.1(3)N1(1). Therefore, virtual FC interfaces get assigned to a VSAN, and the combination of the vfc VSAN assignment and the global VLAN-to-VSAN mapping table enables the Cisco Nexus 5000 Series FIP implementation to choose the appropriate VLAN for a VF_Port. Virtual Fibre Channel interfaces can be bound directly on top of a physical Ethernet interface, or they can be bound to an ENode MAC address, as shown in Figure 8.

Figure 8. vFC Binding Options Virtual FC interfaces bound to a physical Ethernet interface on the Cisco Nexus 5000 Series signal to the software that a direct-attach model is used for that interface. The switch then expects the CNA to be at the other end of the physical Ethernet cable, and it accepts one FLOGI from that one CNA, regardless of its ENode MAC address; moving the CNA to a different physical Ethernet interface on the switch will cause the CNA to become subject to the configuration on the vfc attached to the other interface (if any). After the FLOGI, more FDISC operations can follow if N_port ID virtualization (NPIV) is enabled, with exactly the same semantics as native Fibre Channel interfaces. FIP VLAN discovery advertises only the FCoE VLAN that maps to the VSAN configured on the vfc. Only zero or one vfcs can be bound to a specific physical Ethernet interface at any point in time. Virtual FC interfaces bound to an ENode MAC address signal to the software that a remote-attach model is used to create a virtual link with that specific ENode. FIP FCF advertisements are exchanged on all physical Ethernet interfaces that are not subject to direct-attach bindings, and the ENode can create a virtual link through any of those interfaces, but regardless of the ingress interface, it will always be subject to the vfc that is bound to its MAC address. You should bind virtual FC interfaces to physical Ethernet interfaces whenever possible, and vfc binding to MAC addresses is offered in anticipation of blade switches that will implement only FCoE passthrough switch capabilities. First-generation CNAs that are not capable of exchanging FIP frames will continue to work in a direct-attach configuration with the Cisco Nexus 5000 Series, since the Cisco Nexus 5000 Series Switch will recognize the condition and revert to the pre-FIP exchanges that CNAs expect for FCoE.

Siehe auch

• Fibre Channel over Ethernet
• Fibre Channel
• Internet Protocol over Fibre Channel
• Linux iSCSI Target mit Fibre Channel over Ethernet Unterstützung

Weblinks

• FC-BB-5 Draft Standard (PDF-Datei; 1,9 MB)
• T11 Projektseite
• Linux Open Source Implementierung von FCoE
• LIO - Linux IP Storage Target und Initiator - Upstream ab 2.6.37
• FCoE Entwicklungsseite
• Byte & Switch coverage for FCIA announcements
• IBM Redpaper über FCoE (PDF-Datei; 462 kB)
• [1]

The FCoE Initialization Protocol (FIP) is defined in FC-BB-5. FIP is used to not only for initialization functions such as discovering which Fibre Channel entities are available on a layer 2 Ethernet network and the creation of virtual links, but it is also used to verify the state of the virtual links and to destroy virtual links when there is a need to do so.

The role that FIP plays in both direct connect environments and CEE cloud environments (shown in Figure 33 and Figure 34) is similar. However, while in a CEE cloud environment, FIP allows the lossless Ethernet switch(es) to perform FIP snooping. FIP snooping is required in order to prevent man in the middle types of attacks by allowing the lossless Ethernet switches to Dynamically update ACLs and only allow the ENode that performed FIP to transmit frames with the FPMA (Fabric Provided MAC Address, see FC-BB-5) assigned to it.

When an FCoE initiator or target initializes a virtual link, it is expected that it will do so in a certain order. The first thing that will need to be done is to discover which VLAN the FCoE services are being provided on. Next, the initializing port will need to discover which FCFs are available for login. Finally, FIP login shall be performed.

Once the link has been established, the FIP LKA (Link Keep Alive) protocol will be responsible maintaining that link.