In this video I cover Fibre Channel security through the use of zoning and LUN masking. Scroll down for the video and also text tutorial.
This post is a continuation of Fibre Channel SAN Overview Part One – FCP and Addressing
Want the complete course? Click here to get the Introduction to SAN and NAS Storage course for free
Fibre Channel SAN Part 2 – Zoning and LUN Masking – Video Tutorial[youtube v = QFx2CFgNnuE maxwidth = 100%]
I am starting to work as a SAN/NAS administrator and Neil’s course has been of great help. I can now understand storage/NAS concepts easier. Neil is an experienced professional, you can tell it by this course and the other resources he provides.
For security, zoning is configured on our Fibre Channel switches to control which Fibre Channel ports are allowed to communicate with each other. We allow the ports on the client hosts (the initiators) to talk to the ports on the storage system (the targets). Initiators are not allowed to communicate with each other over the Fibre Channel network. This increases security and reduces traffic, which makes the Fibre Channel network more reliable and stable.
Popular manufacturers of Fibre Channel switches are Cisco and Brocade. The example below is for a Cisco switch, but Brocade uses a similar configuration.
In the example, I've got a couple of servers down at the bottom of the diagram which are clients of the storage system up at the top. Aliases are used to map the long WWPN name to a more convenient alias name chosen by the administrator. I've configured aliases on my Fibre Channel switch for the WWPNs on the servers and on the storage system.
Separate zones are configured for each separate set of connectivity requirements. I configure a zone which enables Server 1 to communicate with the storage system, and a separate zone which allows Server 2 to communicate with the storage system.
Zone name SERVER1 includes member fcalias SERVER1 and member fcalias NETAPP-CTRL1. This allows SERVER1 to talk to its storage.
Zone name SERVER2 includes member fcalias SERVER2 and member fcalias NETAPP-CTRL1. This allows SERVER2 to talk to its storage.
Then, I group all of those zones together into a zone set and apply that on the switch. I've named the zoneset MY-ZONESET, and it includes zones SERVER1 and SERVER2.
With this configuration, Server 1 can talk to its storage and Server 2 can talk to its storage. The two servers can't talk to each other over the fibre channel network because they’re not included in a zone with each other.
Note: This is a simple example to make initial learning easier. Typically we’ll have at least two storage controllers and switches for redundancy. Please see the final part 3 of this series where I cover redundant fabrics for a more realistic example of how zoning is configured in real world deployments.
As well as configuring zoning on our switches, we also need to configure LUN masking on the storage system. It's critical that the right LUN is presented to the right host. If the wrong host was able to connect to a LUN then it would be liable to corrupt it.
The zoning on the switches make sure that the servers can't talk to each other, but they can talk to the storage. So how do I make sure that they can't connect to each other's LUNs? That's where LUN masking comes in.
Zoning on the switches prevents unauthorized hosts from reaching the storage system, and it prevents hosts from talking to each other over the fibre channel network, but it doesn't prevent a host from accessing the wrong LUN once it gets to the storage system. LUN masking is configured on the storage system to lock a LUN down to the host or hosts who are authorized to access it. To secure your storage, you need to configure zoning on your switches and LUN masking on your storage system.
Here's an example of how we would configure LUN masking. Server 1 and Server 2 are both diskless servers. I've configured Boot LUNs for both Server 1 and Server 2 on the storage system. For my Server 1 Boot LUN, the only initiator that can connect to that is Server 1's WWPN. And for the Server 2 Boot LUN, the only initiator that can connect to that is Server 2's WWPN. This prevents the wrong server connecting to and potentially corrupting the other server’s LUN. I could also have used aliases here rather than typing in the WWPN in my configuration.
Switch Domain IDs
The next thing to talk about is Switch Domain IDs. Each switch in in the fibre channel network will be assigned a unique Domain ID. The name can be a bit confusing, because if you’re like me, you’d think a Domain ID would be an ID number which represented the entire domain of switches, but it doesn't mean that at all. The Domain ID is actually a unique ID for each individual switch in that fibre channel network. The Domain ID is a value from 1 to 239 on both Cisco and Brocade switches.
One switch in the network will be automatically assigned as the Principle Switch. It is in charge of ensuring each switch in the network has a unique Domain ID.
Each switch learns about the other switches in the network and how to route to them, based on their Domain ID.
Part 1 of this Fibre Channel tutorial series is available here: FCP and WWPN Addressing
Free ‘Introduction to SAN and NAS Storage’ training course
The video is an excerpt from my Introduction to SAN and NAS Storage training. You can get the entire series for free here:
When you're ready to take your storage knowledge to the next level, you can get my 'Data ONTAP Complete' NetApp Training Course.