02-11-2012 01:26 PM
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
Solved! Go to Solution.
02-12-2012 05:14 AM
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
02-13-2012 02:09 PM
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
02-12-2012 05:14 AM
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
02-13-2012 09:42 AM
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 ;-)
02-13-2012 01:03 PM
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
02-13-2012 02:09 PM
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
02-14-2012 02:28 AM
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
02-22-2012 01:30 PM
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
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: