CSE 533: Project Report Spring 2009
Data Center Ethernet Implementing Fibre Channel Hard Zoning on Ethernet Networks
Krishna Nibhanupudi (SUNY ID 106887824) Rimmi Devgan (SUNY ID 106437638)
Abstract
Fibre Channel is pervasive technology for SANs. The main features that make this technology suitable for SANs is high bandwidth, reliable Data Link transmission, flow control and better network security. However, typical Corporate networks have high bandwidth Fibre Channel for SANs and cheaper Ethernet commodity networks to provide regular network services. This requires dual investment in Fibre Channel and Ethernets. Implementing Fibre Channel primitives on Ethernet would allow for easy consolidation of Fibre Channel networks with Ethernet, enabling low maintenance costs and significant savings in power consumption. While most of the Fibre Channel primitives are now implemented on Ethernet, a few key features are still being researched upon. Particularly 'Zoning' has not been implemented in the current state of the art. In this project we explore various Ethernet primitives that could be exploited to provide zoning and conclude that VLANs provide better support for the same. The particular semantics of VLANs (for Ethernet) and Zones (for FC) are very similar, except for a few key differences. However, the use of VLANs with a few mitigating changes on Fibre Channel stack (on Ethernet) can provide similar levels of security over Ethernet as that on Fibre Channel. .
1
TABLE OF CONTENTS Abstract...................................................................................................................................... 1 1. Introduction ............................................................................................................................ 3 2. Background ............................................................................................................................ 4 2.1 The Fibre Channel Stack .................................................................................................. 4 2.2 Fibre Channel ports .......................................................................................................... 5 2.3 Fibre Channel Addressing ................................................................................................ 5 2.4 Fibre Channel login .......................................................................................................... 5 2.5 Fibre Channel Zoning ....................................................................................................... 6 2.6 Fibre Channel Zoning Architecture ................................................................................... 6 2.7 Fibre Channel over Ethernet (FCoE) ................................................................................ 7 3. Problem Statement ................................................................................................................ 8 4. Approach ............................................................................................................................... 9 5. Design...................................................................................................................................12 6. Test Setup and Results .........................................................................................................14 7. Conclusion ............................................................................................................................16 8. Future Work ..........................................................................................................................16 9. References ...........................................................................................................................16 10. Appendix .............................................................................................................................18
2
1. Introduction Fibre Channel is the technology of choice for Storage Area Networks (SANs). It provides the necessary services for high speed data transfer of huge amounts of data over network; such as congestion free transmission, guaranteed delivery and high efficiency. These services are not provided by Ethernet. The traditional advantages of using Fibre channel (for SAN) instead of Ethernet were cost effectiveness, security, reliable data transfer and multiple topologies. With the advent of Gigabit Ethernet however, the advantage of high bandwidth is now removed (Fibre channel bandwidth is typically 6Mbps). Most of the Fibre channel primitives can now be implemented over Ethernet. Moreover commodity Ethernet networks have lower maintenance costs. Also multiple Fibre Channel HBAs (Host Bus Adapters) can now be replaced by single Ethernet Interface Card. This would result in lower cooling costs and lesser power consumption. Among the several features offered by Fibre channel networks, „Zoning‟ is partitioning of the Fibre channel fabric into smaller subsets in order to aid network maintenance or to provide security or both. Our aim in this project is to explore and implement „Zoning‟ over Ethernet while preserving the Fibre channel semantics of the same. Specifically we target Hard Zoning or zoning enforced in the Fabric (i.e., switches) due to the stronger security offered by it compared to Soft Zoning or zoning enforced at the endpoints (Fibre channel targets or initiators) [5]. A number of ways to implement zoning were studied namely endpoint ACLs, switch based ACLs, VLANs and their relative merits and demerits were compared. We present a way to implement zoning using Ethernet Virtual Local Area Networks (VLAN). VLAN characteristics lend themselves naturally to Fibre Channel Zoning semantics. The design challenges encountered while using VLANs and our solutions to the same are presented herewith. The rest of the report is organized into following sections- We present a brief background of the Fibre Channel primitives and Ethernet. The problem statement is discussed with specific aims and goals of this project. We then present various approaches to implementing Zoning in Ethernet. Design details and issues we encountered (and how we tackled them) are discussed in the design section. The test setup and experimentation results are presented next. Finally we conclude report making important observations.
3
2. Background Fibre Channel provides a logically point-to-point serial channel for the transfer of data between a buffer at a source device and a buffer at a destination device.
2.1 The Fibre Channel Stack
Figure 1 Fibre Channel Stack [13]
FC-0 is the lowest functional layer of the Fibre Channel architecture and describes the physical characteristics of the link connections like transmission speed, point-to-point link lengths etc [18]. FC-1 defines the transmission protocol, including the serial encoding and decoding rules, special characters, and error control [18]. FC-2 describes how data is transferred between Nodes and includes the definition of the frame format, frame sequences, communications protocols, and service classes. The basic unit of data transmission in Fibre Channel is a variable-sized Frame. This layer also defines three classes of service- a connection-oriented (virtual circuit) service, an acknowledged connectionless service and a pure connectionless, or datagram, service. FC-2 is self-configuring and supports point-to-point, arbitrated loop, and switched environments [18]. FC-3 provides a common set of communication services for higher layer protocols above the FC-PH layer (FC_PH is the FC Physical interface that includes FC-0, FC-1 and FC-2). FC-3 provides servers that are accessible to all nodes. Servers that are currently defined include- the Name Server and the Zone server [18]. FC-4 is the top layer of the Fibre Channel protocol architecture and defines the higher layer applications that can operate over a FC infrastructure. The FC-4 provides a way to utilize 4
existing protocols over Fibre Channel without modifying those protocols. It may provide additional services such as buffering, synchronization, or prioritization of data [18].
2.2 Fibre Channel ports Any port on a node device is called an N_Port as compared with a port on a Fabric, which is an F_Port. At the same time, any port that can support arbitrated loop configuration is called an L_Port. Combining these we get NL_Ports and FL_Ports [12]. Ports that connect switches together are called E_Ports. A port that can act as either an E_Port or an F_Port is called a G_Port. A G_Port with loop capabilities is a GL_Port.
2.3 Fibre Channel Addressing Fibre Channels provide a unique 64 bit World Wide Name (WWN) to each Fibre Channel Node. This is not used for routing but to preserve the identity of a node if their layer 2 or 3 address gets changed. A node may have multiple N_Ports each of which have 64 bit WWNs. Also an N_Port is given a 3 byte N_Port ID which is used for frame routing [12].
2.4 Fibre Channel login There are two login procedures in Fibre Channel:Fabric Login (FLOGI) – When a node comes up, all node ports (with exception of some private
NL_Ports) must try to login with the Fabric. The node port transmits a Fabric Login (FLOGI) frame to the well known address 0xFFFFFE. The normal response to this is an Accept (ACC) frame from the Fabric. If a Fabric is present it assigns a 3 byte N_Port ID to it. If a Fabric is not present then an ACC from an N_Port indicates that the requesting N_Port is attached in a pointto-point topology [12]. Port Login (PLOGI) – In order for a node port to communicate with another node port, it must first
perform an N_Port Login with that node port by transmitting a PLOGI frame to the destination node port. Again, the normal response is an ACC frame [12]. In the fabric topology, Fibre channel nodes use PLOGI to a Name Server located on a switch. The name server maintains a database of objects that allows each fabric device to register and query information like name, address and class of service of other participants. The name server is accessed by performing a PLOGI to the well known address 0xFFFFFC. An N_Port registers itself with the Name Server after performing a PLOGI in this way. An end point then queries the Name Server to get the list of all port addresses registered with the switch. This is done by performing a “get all next” which takes the form of “Respond with all parameters of the next higher registered port ID than port ID x”. With repeatedly issuing this query starting with own Port ID and then substituting the response Port IDs in subsequent requests, a list of all registered ports with the Name Server can be made. Once the end point receives a list of N_Port IDs it can establish connections with each by performing PLOGI to each. The Name Server also provides a notification service that allows nodes registered for notification to receive messages when N_Ports enter or leave the fabric. These are called Registered State Change Notifications or RSCN [3]. 5
2.5 Fibre Channel Zoning Zones within a Fabric provide a mechanism to control frame delivery between FC devices ("Hard Zoning") or to expose selected views of the fabric ("Soft Zoning"). Communication is only possible when the communicating endpoints are members of a common zone [5]. An N_Port may be a member of one or more Zones. Zones in a Fibre Channel serve the following purposes:1. Ease in maintenance – By separating the Fibre channel as per functionality or business groups (HR, Finance etc), zones aid in making the task of a Fibre Channel administrator easier. 2. Security – By controlling frame delivery between Fibre channel devices either physically (hard zoning) or logically (soft zoning), zones also provide security. There are mainly two types of Zoning methods in the Fibre Channel:Soft zoning – This is enforced at the endpoints (e.g., host bus adapters (HBAs)) by relying on
the endpoints to not send traffic to a device not belonging to its zone [5]. It makes use of the Name Server on switches to enforce zones. It‟s simpler to administer since no re-configuration is required when a device is moved from one port to another. This form of zoning, however, is susceptible to WWN spoofing attacks. In it a rogue port may spoof a valid WWN to gain unauthorized access to a zone since soft zoning does not tie WWNs to specific ports [2]. Also if a node directly addresses a destination port that is not in its Zone, the frame will reach the destination as there is no physical isolation between nodes. Hard zoning – This is enforced in the Fabric (i.e., switches) and physically isolates traffic
between different zones [5]. In this project we mainly focus on Hard Zoning because of the stronger security features of the same even though it is less flexible than the Soft Zoning approach.
2.6 Fibre Channel Zoning Architecture Zones in the Fibre Channel are configured via a Fabric Zone Server. A Zone Server [5] is part of the FC distributed management services, run on FC switches. One or more Zones may be collected into a Zone Set, and a Zone may be a member of more than one Zone Set. A Zone Set can be activated or deactivated as a single entity across all Switches in a Fabric. An Active Zone Set is the Zone Set currently enforced by a Fabric.
6
Figure 2 The Zone Set Database [5]
Interactions with the Fabric Zone Server are via two distinct set of management requests [5]:Basic set - It provides compatibility with earlier versions of Fibre Channel's Generic Services
specification. Enhanced set – Any management action using the Enhanced Management set requires a server
session to be set up. A server session is set up using the FC-GS-5‟s (Fibre Channel Generic Service 5) Common Transport (CT) protocol. A zone server session is delimited by CT protocol requests, Server Session Begin (SSB) and Server Session End (SSE). Setting a server session requires:1. The Zone Server to lock the Fabric- The switch that receives the SSB request becomes the 'managing' switch and it tries to lock the Fabric using the Fabric Management Session Protocol by sending an Acquire Change Authorization (ACA) request to all other switches in the Fabric. Depending on responses from other switches, the Fabric locking succeeds or fails. 2. If Fabric is locked successfully the server session can be established. Now commands can make changes to Zone sets, deactivate or activate Zone sets etc. 3. The subsequent SSE request causes a Release Change Authorization (RCA) request to all other switches, and thus, the Fabric to be unlocked.
2.7 Fibre Channel over Ethernet (FCoE) Fibre Channel over Ethernet (FCoE) is a standard being developed by INCITS T11. The FCoE protocol specification maps Fibre Channel primitives to Ethernet. The primary purpose of this standard is I/O consolidation - the sharing of both Fibre Channel and Ethernet traffic on the same physical cable. FCoE provides the capability to carry the FC-2 layer over the Ethernet layer. The FCoE stack performs encapsulation/decapsulatoin of the Fibre Channel frame into an Ethernet frame and this is called an FCoE frame [10].
7
Traditional Fibre Channel fabric switches perform routing based on FC N_Port IDs. Fibre Channel is typically point-to-point and does not need an address at the link layer but Ethernet require FCoE to use Ethernet MAC. However, FCoE MAC addresses should be different from LAN MAC addresses. The FCoE MACs are generated from FC N_Port IDs and FC – OUI or Organizationally Unique Identifier given by IEEE [9]. We refer to this generated MAC whenever we say MAC in the rest of the document unless otherwise mentioned.
Figure 3 FCoE Mapped MAC Addresses [9]
The open-FCoE implementation, provided by open-FCoE.org [11] has been used by us in the project, a brief explanation of its components follows:FCoE initiator – This is the SCSI Initiator over the FCoE stack. A SCSI Initiator is the endpoint
that initiates a SCSI session by sending SCSI commands. FCoE target - This is the SCSI target over the FCoE stack. A SCSI target is the endpoint that
waits for initiator‟s commands a SCSI session by sending SCSI commands. Fibre Channel Forwarder - Fibre Channel Forwarders (FCFs) provide the connectivity between
FCoE initiators/targets (on Ethernet) and conventional Fibre Channel fabrics. They essentially encapsulate/ decapsulate FC frames to FCoE Ethernet frames and vice versa.
3. Problem Statement The network administrator enters the Zoning configuration in the form of a Zone Set into the Zone Server database. The Zone Set is defined as a set of MAC lists with each list corresponding to a Zone. This Zone Set needs to be interpreted and used to configure Ethernet Switch ports such that different nodes in an Ethernet network are partitioned off into segments (VLANs in our approach) that follow the Zone Set semantics.
8
4. Approach We pursued several approaches to implementing Zoning on the Fibre Channel before deciding on using VLANs to implement Hard Zones on Ethernet. We give a brief description of other approaches pursued and their limitations before describing in detail the VLAN approach. 1. Endpoint Access Control Lists- ACLs can be implemented in the FCoE (Fibre Channel over Ethernet) protocol stack to drop packets which don‟t fit in a set of rules (don‟t belong to the zone to which the endpoint belongs). These ACLs will need to be implemented at both the source and destination endpoints and would extend our system‟s trust base to the endpoints as well. This method offers great flexibility as the endpoints are not tied in any way to their switch ports. Thus, it can be used to implement Soft Zoning in Ethernet. However, it suffers from the same limitations as Soft Zoning- we would need the endpoints to be well behaved and WWN (or MAC) spoofing would be possible. 2. Switch based Access Control Lists – In switch based ACLs packets are filtered at the switch ports based on SRC/DST MAC addresses and EtherType. Given a Zone Set this approach would require us to generate ACLs for each port on a switch to allow packets belonging only to the zone of the N_Port connected to that port to go through. The advantages of using this approach are that it easily allows for an N_Port to belong to multiple Zones and is intuitively closest to FC Zoning approach. However the approach suffers from some serious limitations. Since FC Zones are much complex than Ethernet ACLs, Zone to ACL conversion could cause scaling problems on Ethernet switches in that it would cause the ACL limit per switch to be easily exceeded ( in a typical Cisco 2960 switch with 48 ports and 512 ACLs per switch, on an average only 11 ACLs per port will allowed [14]). Implementing broadcasts using ACLs is also a major issue. Apart from these ACLs suffer from the traditional disadvantages – ACL maintenance (revocation/modification) is not easy, even when this is automated verifying that the ACLs are configured correctly is a tough job. 3. Virtual Local Area Networks (VLANs) - VLANs partition an Ethernet into multiple broadcast domains. Communication between different VLANs happens via routers and we can have IP based ACLs at the router to allow/disallow VLANs from communicating. VLAN features lend themselves naturally to Zoning semantics. We configure one VLAN per Zone, which allows for straightforward traffic isolation between different Zones. Since FC traffic uses the SCSI protocol, no IP based addressing/routing is done and so we are even saved from configuring routers. However, we are faced with the following issues faced while mapping Hard Zones to VLANs:9
How to have multiple Zones per port using VLANs? Normal Ethernet switch ports can only be part of one VLAN at a time. However, most commodity Ethernet switches offer the ability to mark a port as a Trunk port. Trunk ports can be configured to carry traffic for a set of specified VLANs. Trunks use the 802.1Q protocol to add a 4-byte VLAN identifier to each frame. This is used on both ends to identify to which VLAN each individual frame belongs. The endpoint NIC would also need to understand VLAN tags this allows. Linux kernel 2.1.14 onwards supports VLAN trunking. In order to use 802.1Q trunking, we simply set the CONFIG_VLAN_8021Q option when configuring the kernel [7].
How to ensure that general fabric services are accessible? We need to ensure that our VLAN based Zone setup allows all nodes to access generic FC services such as the Name Servers etc present on FCoE (Fibre Channel over Ethernet, explained later in the Design section) enabled switches. In order to allow this we simply need to ensure that the port attached to the FCF (Fibre Channel Forwarder – the FC to Ethernet interface on an FCoE switch, explained in the Design section) is part of all VLANs.
How are frames travelling from FC fabric to Ethernet across an FCoE switch handled? When a frame crosses over from a Fibre Channel Fabric to an Ethernet Network or vice versa we would require the FC Forwarder on the intermediate FCoE switch to apply the appropriate VLAN tags to the Ethernet frames based on the Zone that the SRC and DEST N_Port IDs belong to. For this we store the zone to VLAN mapping information with the FCF. The FCF will look up the Zone that a SRC and DEST N_Port ID belong to and then use the VLAN corresponding to this Zone to tag the FCoE frame (which is an Ethernet frame that encapsulates the Fibre Channel frame) it generates.
For an end point node belonging to multiple zones which VLAN ID to use when sending out frames? An N_Port can be part of multiple VLANs. The N_Port will obtain the list of MACs in its zone by querying its Name Server using the PLOGI process explained earlier. We would need the N_Port to add the correct VLAN tags to its outgoing packets because otherwise either the packet would be dropped by the VLAN filtering done by the switch port or there will be no MAC in the VLAN corresponding to the tag attached. We have tackled the problem in the following way:1. Initially after an N_Port receives a list of MACs it can access, it will perform a PLOGI to each of the MACs. A table of MACs vs VLAN tag is maintained which initially has the VLAN column empty. We would send out the PLOGI on each of the VLANs the source N_Port is a member of.
10
MAC
VLAN tag
00-B0-D0-86-BB-F7
1
00-B0-D0-78-22-98
5
-
-
Figure 4 MACs vs VLAN tag table
2. Each of the PLOGIs sent will be responded to. We use the VLAN tag of the incoming response to sort out the MACs into different VLANs. For this purpose we populate the MAC vs VLAN table as we receive the responses. A potential issue in this approach is the handling of destination MACs that share more than one VLAN with the source. With our approach such a destination MAC will be associated with the VLAN tag of the packet that arrives first in response to the PLOGI, this leads to no problems. From now on the VLAN tag associated with a MAC is used in any packet addressed to that MAC.
How are broadcasts handled? Broadcasts will be sent on all VLANs to which the endpoint belongs. This is in keeping with FC zone semantics. However, we may face the issue of a node receiving multiple broadcasts if it shares multiple Zones with the source of the broadcast. A simple solution to this is to only consider broadcast packets from a source MAC if the VLAN tag associated with the packet is the one in our MAC vs VLAN tag table, all other broadcast packets are dropped.
11
5. Design The basic design of our approach is given by the following diagram:-
Figure 5 FC Zoning over Ethernet - Basic Design
The different components of the system are:1. Endpoint Server\Initiator – These are the SCSI initiators that run the open-FCoE stack on Linux kernel version 2.6.28-rc5. 2. Storage Array\Target – These are the SCSI targets that run the open-FCoE stack on Linux kernel version 2.6.28-rc5. 3. FCoE Switch Emulator - Since we lack an actual FCoE switch, we had to write a FCoE switch emulator. The emulator is configured by editing two files – switch.conf and zone.conf. The first configuration file provides end point MAC address to Ethernet switch port mapping. Each entry in this file is of the form
,,. The second configuration file provides zone information by listing out all the endpoint MAC addresses in same zone together. Each entry is of the form <# of entries>,[,...].
The different components of the FCoE switch emulator are as follows:12
a. Name Server Emulator – The Name Server Emulator is a C program that receives PLOGI requests, from N_Ports and stores them in the following data structure:struct registered_NPorts{ int Port_ID; /* The N_Port ID */ char Port_MAC[MAX_ADDR]; /* The MAC associated with * the port */ int VLAN_tag[NVLANS];/* VLAN tags for the port */ int vlan_count; /* Number of VLANs port is member of */ struct registered_NPorts *next; /* Pointer to next * node */ };
The VLAN_tag array is filled in using the output from the Mapping utility (explained below). The emulator also responds to “get all nodes” queries to return the registered ports belonging to the requesting nodes zones. The “get all nodes” query is handled as described in the Background section. b. Mapping Utility - This utility is a combination of C code and Bash script. It essentially reads the two configuration files zone.conf and switch.conf and generates command list for configuring the ethernet switches. These commands are then executed on the respective switches by the shell script. This utility also populates a database containing mapping of FC Zone to VLAN Ids (explained below). c. Database containing mapping from FC Zone to VLAN Ids – This database is populated by the mapping utility. It is used by the FCF to find the correct VLAN Id to tag a packet travelling from the FC fabric to Ethernet portion of the network. d. Fibre Channel Forwarder – We use the open-FCoE implementation of the Fibre Channel Forwarder. However, adding of the VLAN tag to a packet travelling from the FC fabric to Ethernet portion of the network using the database in part c. has not been implemented yet. 4. Ethernet switches – We use Cisco Catalyst 2960 Ethernet switches that provide 802.1Q tagging as well as the VLAN Trunk Protocol (VTP) that helps in reducing unnecessary traffic between Ethernet switches. These switches are configured by the mapping utility. We also utilize Port Security mechanism of the Catalyst 2960 switches that prevent N_Port/WWN/MAC spoofing by associating an Ethernet switch port to a MAC or list of MACs. Only these listed MACs are allowed to connect to the network via the port.
13
6. Test Setup and Results We used the following setup to test our design:Uplink
130.245.130.39 FCoE Initiator
5
2 Switch 2 (Cisco Catalyst 2960)
1 1
130.245.130.35 FCoE Switch Emulator
5 Switch 1 (Cisco Catalyst 2960)
2
(130.245.130.33) 4
130.245.130.31 FCoE Target
(130.245.130.34) 3
3
130.245.130.36 FCoE Target
Monitor traffic (eth3 at 130.37)
4 130.245.130.37 FCoE Initiator
The input given is:switch.conf= #switchname,port,mac SWITCH1,1,00:21:9b:e7:97:58 SWITCH1,5,00:21:9b:e7:98:58 SWITCH1,3,00:21:9b:e7:99:58 SWITCH1,4,00:21:9b:e7:90:58 SWITCH2,2,00:21:9b:e7:87:58 SWITCH2,5,00:21:9b:e7:88:58 SWITCH2,3,00:21:9b:e7:89:58 SWITCH2,4,00:21:9b:e7:80:58 zone.conf= #The entries are , 3,00:21:9b:e7:98:58,00:21:9b:e7:89:58,00:21:9b:e7:80:58 2,00:21:9b:e7:98:58,00:21:9b:e7:90:58 Following Zones are then Generated zone2 has 3 macs ->00:21:9b:e7:98:58, 00:21:9b:e7:89:58, 00:21:9b:e7:80:58, zone3 has 2 macs ->00:21:9b:e7:98:58, 00:21:9b:e7:90:58, Corresponding VLANs generated are: switch_name [SWITCH1], switch_port [1], VLANs->
14
switch_name switch_name switch_name switch_name switch_name switch_name switch_name
[SWITCH1], [SWITCH1], [SWITCH1], [SWITCH2], [SWITCH2], [SWITCH2], [SWITCH2],
switch_port switch_port switch_port switch_port switch_port switch_port switch_port
[5], [3], [4], [2], [5], [3], [4],
VLANs-> VLANs-> VLANs-> VLANs-> VLANs-> VLANs-> VLANs->
3,
2,
3, 2, 2,
Specifically, port 5 of switch1 belongs to two VLANs 3 and 2. The membership from default VLANs is removed. Ports 1 and 3 of switch 1 and ports 2 and 5 of switch 2 belong to the default VLAN (with vlan id 1). Please see the appendix for the exact commands issued to the switches.
Security Implications:The key difference difference we observed between VLANs and Zones is that the end point in a fibre channel is unaware of its membership to a zone. In a VLAN, however, the membership of the endpoint is known to it since VLAN tag Ids are sent in incoming ethernet frames. Because of this feature the endpoint can spoof the VLAN ID and attempt communication over a VLAN to which it does not belong. However, this is avoided in our implementation since we configure switch ports (in trunk mode) to allow traffic for specific VLANs to pass. This prevents a rogue endpoint from sending unsolicited traffic. Also, it is much easier to spoof MAC address in ethernet then compared to spoofing WWN/ Nport-id in Fibre Channel. Since our database only maintains a MAC address to WWN/N-portid mapping, a spoofed ethernet frame could compromise the security of the whole network. We prevent this using the 'port-based security' feature in commodity ethernet switches. This allows us to specify a list of MAC address associated to each port of ethernet switch. Any traffic originating on these port has to be generated at one of the MAC address on the list (the source MAC address is thus validated). This prevents rogue endpoints from spoofing MAC address to gain illegal access.
15
7. Conclusion Virtual LANs on Ethernet by themselves do not offer strong security dictated by semantics of Zoning in Fibre Channel. In particular, spoofing of both VLAN Ids and MAC address is a concern when guaranteeing the level of security desired in FC networks. We have prototyped implementation of Zoning for Fibre Channels in Ethernet. To provide similar levels of security, we used port based security in conjunction with VLAN using trunk ports. This allows a single port in Ethernet switch to belong to multiple VLANs while at the same time performing ingress filtering based on VLAN ID and MAC address to prevent spoofing.
8. Future Work The FCF in current prototype doesn't use the Zone to VLAN ID mapping Database while sending out packets on ethernet interface. This should be modified to allow traffic to be sent on specific VLANs. The Zone Server on Fibre Channel has MIB that can be integrated with MIB of the FCF using SNMP or some other network management protocol.
9. References 1. Tom Clark, “Designing storage area networks”. Published by Addison-Wesley, 2003. 2. Thomas C. Jepsen, “Distributed storage networks: architecture, protocols and management”. Published by John Wiley and Sons, 2003. 3. Alan F. Benner, “Fibre Channel for SANs”. Published by McGraw-Hill Professional, 2001. 4. Ulf Troppens, Rainer Erkens and Wolfgang Müller, “Storage networks explained: basics and application of fibre channel SAN, NAS, iSCSI and InfiniBand”. Published by John Wiley and Sons, 2004. 5. C. DeSanti, H.K. Vivek, K. McCloghrie and S. Gai, “Fibre Channel Zone Server MIB”. August 2007. (http://www.rfc-editor.org/rfc/rfc4936.txt). 6. FCoE Commentary EMC/HP/IBM. July 13, 2007. (http://www.t10.org/ftp/t11/document.07/ 07 -408v1.pdf) 7. Paul Frieden, VLANs on Linux. March 11, 2007. (http://www.linuxjournal.com/article/7268). 8. FCoE: Ethernet Direct-Attached Fabrics (EDAF). (ftp://ftp.t10.org/t11/document.07/07608v0.pdf) 16
9. Silvano Gai, “FCoE Addressing”. T11/07-547v0, October 2007. (http://www.t10.org/ftp/t11 /document.07/07-547v0.pdf). 10. Fibre Channel Industry Association, “Fibre Channel over Ethernet in the Data Center: An Introduction”. 2007. (http://www.fibrechannel.org/OVERVIEW/FCIA_SNW_FCoE_WP_ Final.pdf). 11. Open-FCoE. (http://www.open-fcoe.org/wordpress/) 12. Fibre Channel Tutorial (http://www.recoverdata.com/fc_tutorial.htm#Fabric) 13. Fibre Channel: A Tutorial. VMEbus Systems. March-April 2000. (http://www.vmecritical. com/ pdfs/FCIA.Apr00.pdf). 14. Cisco Manual – Catalyst 2960. 15. FC Switch Fabric-2, NCITS working draft proposed American National Standard for Information Technology. (http://www.t11.org/ftp/t11/pub/fc/sw-2/01-365v0.pdf). 16. Fibre Channel Systems: Putting It Together. (http://www.fibrechannel.org/solutions/ Systems/Systems.pdf)- Cover page figure reference. 17. C. DeSanti, V. Gaonkar, H.K. Vivek, K. McCloghrie, S. Gai, “ RFC 4438 FC Name Server MIB”. April 2006. (http://www.rfc-editor.org/rfc/rfc4438.txt). 18. Walter Goralskiand and Gary Kessler, “Fibre Channel: Standards, Applications, and Products”. December 1995. (http://www.garykessler.net/library/fibre_channel.html).
17
10. Appendix The Zone configuration is primarily feed into two configuration files
1. switch.conf 2. zone.conf The sample file we used is for experimentation is switch.conf
zone.conf
The primary data structures used are linked list. These are enumerated below-
18
