cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5346
Views
4
Helpful
6
Replies

FC Domain ID per VSAN best practice

eric.krejci
Level 1
Level 1

Hi,

I'm actually wondering of the best practice about the FC domain ID.

when configuring a new switch member of a fabric with multiple vsans, is it better to set the fcid as static or prefered?

if you go for a prefered settings, is it a good Idea to set the same fcid for every vsan in the same switch?

Ex:

switch1:

- vsan 1 - domain id 10 preferred

- vsan 2 - domain id 10 preferred

switch 2:

- vsan 1 - domain id 20 preferred

- vsan 2 - domain id 20 preferred

so is it a good configuration to set it like that? having for a switch the same fcid for every vsan.

thank you

Eric

Sent from Cisco Technical Support iPad App

2 Accepted Solutions

Accepted Solutions

Eric

Not 100% sure if it's "Cisco best practice" or not - but I ALWAYS use static domain ID's.  There is still a fair number of old systems that cannot tolerate a domin ID change.

As for the actual ID's to use, that is really up to you.  I tend to use a system as follows:

All my switches are xxxxxxxxxxAnn or xxxxxxxxxxBnn, A or B for the seperate fabrics and nn being 01 to 99 for the switch number. (I've never had to implement more than 99 switches in a fabric yet!)

VSAN's are nn00, nn being 01 - 99

The Domain ID's are the VSAN ID + the switch number.

With that, with any domain ID, they are unique and I know what switch it's on and which VSAN it's in.

BTW, It is bad practice to use VSAN 1 - but i'm assuing you were only using that as an example.

Steven

View solution in original post

Steven,

Changing the domainID, is only disruptive to those devices within the VSAN and not to devices in other VSANs. This is assuming that you do not have IVR related traffic flowing through that switch's VSAN.    If you choose to change the FCID of the VSAN on a particular switch, it is best of suspend/no-suspend the VSAN on that switch rather than using the fcdomain's disruptive restart feature.  This is because when you issue the fcdomain disruptive restart feature, it broadcasts out within the VSAN, a RCF frame (ReConfigure Fabric), which tells all switches in the VSAN to obtain new domainIDs.  A pretty disruptive process.  However, if you just suspend/no suspend the VSAN on that one switch, then the other switches in that VSAN do not give up their respective domainIDs.

Your observation about AIX/HPUX is correct, but it is specific to the FCID that is assigned to the storage ports and not the HBAs.  When you have those two platforms, you always want to make sure the switch where the storageports are is configured for static domainID and persistent FCID (that way the FCIDs are always the same).  This is due to the fact that the FCID of the storage port is embedded in the device path of the server.

Hope this helps,

-Seth

View solution in original post

6 Replies 6

Eric

Not 100% sure if it's "Cisco best practice" or not - but I ALWAYS use static domain ID's.  There is still a fair number of old systems that cannot tolerate a domin ID change.

As for the actual ID's to use, that is really up to you.  I tend to use a system as follows:

All my switches are xxxxxxxxxxAnn or xxxxxxxxxxBnn, A or B for the seperate fabrics and nn being 01 to 99 for the switch number. (I've never had to implement more than 99 switches in a fabric yet!)

VSAN's are nn00, nn being 01 - 99

The Domain ID's are the VSAN ID + the switch number.

With that, with any domain ID, they are unique and I know what switch it's on and which VSAN it's in.

BTW, It is bad practice to use VSAN 1 - but i'm assuing you were only using that as an example.

Steven

Hi Steven,

thank you for your answer.

Your ID's numbering sounds good.

static is more or less the where I thought I would go for. the only point that I don't know is changing the FCID of an existing switch.

I guess that once the ID is changed to a proper one and in static mode a disruptive restart of the domain is necessary.

did you already perform such "migration"?

many thanks

Eric

P.S. VSAN 1 was only for the example ;-)

Eric

Yes a domain ID change is disruptive to everything on that switch.

I've never had to do a migration like that yet.  However, assuming you have dual redundant fabrics, and all hosts & storage are correctly connected and configured, you can make the change and not loose access to data.

There will be remedial work on some OS's, the 2 that immediately spring to mind is AIX (WITHOUT dynamic tracking enabled) and older HP-UX (I've no idea if it's "fixed" in newer versions as it's been a while since I used it)

Out of interest, what storage & multipathing S/W are you using?

Thanks

Steven

P.S. Feel free to rate my earlier post if it was helpeful

Steven,

Changing the domainID, is only disruptive to those devices within the VSAN and not to devices in other VSANs. This is assuming that you do not have IVR related traffic flowing through that switch's VSAN.    If you choose to change the FCID of the VSAN on a particular switch, it is best of suspend/no-suspend the VSAN on that switch rather than using the fcdomain's disruptive restart feature.  This is because when you issue the fcdomain disruptive restart feature, it broadcasts out within the VSAN, a RCF frame (ReConfigure Fabric), which tells all switches in the VSAN to obtain new domainIDs.  A pretty disruptive process.  However, if you just suspend/no suspend the VSAN on that one switch, then the other switches in that VSAN do not give up their respective domainIDs.

Your observation about AIX/HPUX is correct, but it is specific to the FCID that is assigned to the storage ports and not the HBAs.  When you have those two platforms, you always want to make sure the switch where the storageports are is configured for static domainID and persistent FCID (that way the FCIDs are always the same).  This is due to the fact that the FCID of the storage port is embedded in the device path of the server.

Hope this helps,

-Seth

Seth

Indeed, on reading my post again, i wasn't particularly clear on a couple of points!  My bad for assuming , but yes, It would only be the  devices on that VSAN that would be affected.

Yes you are also correct on the FCID change on target ports affecting those hosts. So Eric, if the STORAGE devices are not on the particular switch you are changing, you wil be OK whilst changing that one.  You may not when you get to the switch with the storage connected.

Thanks for the clarification Seth

Steven

Sorry for my late reply. I was off sick.

I will take into consideration every facts you just highlighted.

I might go for a complete rebuild of the fabrics. I will try it out on a test environement first.

thank you again

Eric

Sent from Cisco Technical Support iPad App

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: