Boot from SAN: WWPN or WWNN ?

[TronAr]

Hi,

I'm trying to nail some FC concepts, coming from networking side...

I think I have the right concept on WWNN and WWPN, although I don't know the details, both

are sent on FLOGI and PLOGI, and they could be used to differentiate a path in the topology

to a common node (WWNN) via different ports.

And here is what I don't get. If this is the case, why is that I always see a WWPN used as a SAN target

instead of the (more useful, highly available ?) WWNN ?

Learning,

-Carlos

[rcporto]

A general best practices from all SAN vendos is to never use WWNN for zone definitions.

[TronAr]

Well, that's good to know but:

-SAN boot target and zones are different (related) things

-I'd love to know the "why", not only the "what" to do.

AFAIK, zoning is just a security (authorization) method controlled by the fabric.

I can see that doing it based on WWPNs is finer than doing it at WWNNs, also WWNNs are "movable" so to say, so security based on that could be flaky. That's more or less as far as I can see now.

Thanks,

-Carlos

[VirtuallyMikeB]

Hello,

Don't forget that fibre channel is more than just initiators and targets.  There's a network in between that must be able to switch/route, address, scale, and provide management, control, and security.  Node names are used as the name implies, to identify devices in the network.  HBAs are not the only devices.  FC switches have WWNNs, as well.  Just like an HBA has ports that are assigned WWPNs, FC switches have ports that are also assigned WWPNs.  Just from this basic understanding, you can probably see how zoning based on WWNNs is not what was intended by the creators of the protocol.  You'd probably get a kick out of reading some of the original FC standards.  It's dry, sure, but if you really want to know how "stuff" ticks, go read them.  In short, you don't zone by WWNNs because that's not how it works.

This question reminds me of when I was studying my for CCNA.  I had a buddy ask the instructor, "Why can't we just route by MAC address?"  Of course, this was before TRILL.  The answer was, that's not how it works.

I thought I had a grasp on FC after reading Cisco docs and even implementing it, but then I found Rick Mur's Fibre Channel 101 video.  It does a much better job of explaining things than reading.  CCIE Data Center :: FiberChannel 101 - YouTube

All the best!

Mike

-----------------------------------------

Please consider marking this answer "correct" or "helpful" if you found it useful.

Mike Brown

VMware, Cisco Data Center, and NetApp dude

Consulting Engineer

michael.b.brown3@gmail.com

Twitter: @VirtuallyMikeB

Blog: http://VirtuallyMikeBrown.com

LinkedIn: http://LinkedIn.com/in/michaelbbrown

[TronAr]

Mike,

thanks for the reply. But my doubt is not related to zoning.

What I don't understand is why is that PNs are used for SAN boot targets.

But given that zoning is coming back again and again, it might be related I'll keep digging.

-Carlos

[VirtuallyMikeB]

Hi Carlos,

I don't think we need to talk about *boot* targets in particular.  The conversation applies equally to data LUNs.  I don't think you can necessarily separate targets from zoning, either.  Even if you don't configure explicit zones, the concept of the default zone (1) will apply.  FC initiators, targets, zones, WWNs, are all inter-related and need to be a part of the same conversation.

So in Zen Master form (not that I'm a Zen Master, just in his form!), I'll answer your question with a question.  You asked,

Why is it that WWPNs are used for [boot] targets?

And I ask,

Why do you have to use IP addresses to communicate on an Ethernet network?

The answer is, that's the way it was designed.  WWNNs are not meant to be used as targets.  That's not how it works.

In all seriousness, the analogy between IP network requirements and FC network requirements is only meant to point out that protocols are designed with certain implementation rules that result in a deterministic system.

For those reading and thinking that two hosts on an IP network actually send information from MAC to MAC, try not having IP addresses on your hosts and communicating.  Hint: start by ripping out the IP from your TCP/IP software stack first 😉

All the best!

Mike

-----------------------------------------

Please consider marking this answer "correct" or "helpful" if you found it useful.

Mike Brown

VMware, Cisco Data Center, and NetApp dude

Consulting Engineer

michael.b.brown3@gmail.com

Twitter: @VirtuallyMikeB

Blog: http://VirtuallyMikeBrown.com

LinkedIn: http://LinkedIn.com/in/michaelbbrown

[TronAr]

Mike,

your IP metaphore does not work for me. I know why IP is there and why MACs are there.

But, frankly, I'm thinking of NNs in the same way you think of NET addresses in OSI.

An address that is independent of  the topology.

And I think boot targets are special. Boot targets have to be managed before you have a complete system up,

so multipathing may not yet be ready for prime time.

But again, I should go and read and understand. It just does not make sense yet.

[VirtuallyMikeB]

Hi Carlos,

The IP analogy was only to point out that it's by design that one requires IP addresses to communicate.  In the same way, it's by design that one must use WWPNs to communicate over an FC network.  That's how FC was designed.  That's it.

And configuring a boot target is really only unique or special to the booting host and the storage array, not the FC network itself.  The network continues to perform FLOGIs and PLOGIs, continues to allocate FCIDs, continues to check zoning configuration to verify who can talk to who, continues to pass on LUN IDs regardless of whether they're boot LUNs or not.  The fabric operation doesn't change whether we're talking about boot targets, data targets, or tape targets.

Multipathing is also unique to hosts.  The fabric design should ensure multiple available paths so multipathing works, sure, but MPIO is a host-side feature and not fabric-specific, per se.  Since multipathing won't necessarily be up and running, we configure host HBAs for primary and secondary boot paths.  Again, nothing special regarding the fabric.

Boot from SAN is unique to hosts (and arrays) and not the fabric.  The fabric acts like the universe - it's just there regardless of what we're doing here on Earth.  The fabric is just there, regardless of whether we're booting from SAN.  It will enable us to log in and it will enforce our zoning, whether at boot time or when accessing data.  From there, it's all on the host and array to agree on boot LUN configuration.

I hope that helps a bit more.

All the best,

Mike

-----------------------------------------

Please consider marking this answer "correct" or "helpful" if you found it useful.

Mike Brown

VMware, Cisco Data Center, and NetApp dude

Consulting Engineer

michael.b.brown3@gmail.com

Twitter: @VirtuallyMikeB

Blog: http://VirtuallyMikeBrown.com

LinkedIn: http://LinkedIn.com/in/michaelbbrown

[TronAr]

Mike,

thanks again. My question was always related to why it is used a PN in the boot target for SAN booting.

It might not been clear, but in the configuration of the host.

Being (even more) picky, some IBM hosts do require NN and PN for the target, so it seems it's not "by design" but

a de facto standard,

I don't know now if a LUN that is provided at a WWPN should also be accesible at the corresponding WWNN. I guess not, and

all the thing revolves out of a security issue...

-Carlos

[rcporto]

From Redbook SAN Boot Implementation and Best Practices Guide for IBM System Storage you can find some more explanation WHY use wwpn instead wwn (at least on initiator side):

[VirtuallyMikeB]

Actually, that makes a lot of sense. Thanks.

[chriswahl]

Quite simply, the WWPN is used to create a predictable path to the boot LUN. Quite often you'll have multiple boot policies - one going to a pair (or more) of WWPNs and another going to the opposite WWPNs - to avoid stressing the SAN target. I rarely advise using the WWNN for zoning in just about any use case (including boot) because you no longer have a deterministic path to the target across all available target ports.

[TronAr]

Chris,

thank you for taking the time to read and respond.

Again, you are bringing zoning back into the scene, so now I'm strongly considering that the reason is indirect, i.e.. it's a security mandated thing.

Yup, I can see the brittleness of zoning using WWNNs. In fact, there seems to be a design "party" that even considers soft zoning as brittle.

My concern was about the loss of (high?) availability for the boot process on a port down situation.

Booting from a WWNN was, in that respect, a superior option.

Obviously you can compensate that by setting two boot targets I guess it is clear now.

[chriswahl]

Your boot from SAN config should allow for multiple WWPN entries. I usually use four WWPNs: two primary and two secondary. The ordering would be controller 1 port 1, controller 2 port 2, controller 1 port 2, controller 2 port 1.