Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

difference between switch DID and VSAN DID

I am new to the Cisco switches. So here is a dumb question. I was under the impression that switch has a unique doamin ID. But I see a unique domain ID for each VSAN also. Why is that and is it being set by the switch itself or defined manually ? I have a single 9216 switch with a few VSANs.

Much appreciated

TIA

-Shynee

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: difference between switch DID and VSAN DID

Hi Shynee,

You are correct in saying that the domain_ID is unique per switch. However, since each vsan runs independent fabric services (read: independent from other vsans) it requires a domain_ID. Now, this ID can be the same for all vsans and can setup in multiple ways:

- automatically within the established range - in which case the principal switch controls the assigment.

- statically (manually configured) in which case you can still control such setup.

- within a particular range - which you can control from the principal switch also.

This is a very high-level explanation. I encourage you to review the SANOS documentation for more details.

Thanks

Carlos Gonzalez

SAN Test Lab - RTP

DCBU Customer Operations Group

3 REPLIES
Community Member

Re: difference between switch DID and VSAN DID

You might have worked on lower end brocade/Mcdata SAN Switches, where you have only 1 DID per switch but if you connect multiple switches by ISLs you need to have different DID for each switch.but in cisco MDS you can create Virtual SANs and you can define DID manually as well, that's the same as VSAN ID.so, when you create multiple VSANs under 1 fabric/Switch, you need to have different VSANs ID.

I hope that is the case, but wud love to hear if I'm wrong.cheers...bye

Cisco Employee

Re: difference between switch DID and VSAN DID

Hi Shynee,

You are correct in saying that the domain_ID is unique per switch. However, since each vsan runs independent fabric services (read: independent from other vsans) it requires a domain_ID. Now, this ID can be the same for all vsans and can setup in multiple ways:

- automatically within the established range - in which case the principal switch controls the assigment.

- statically (manually configured) in which case you can still control such setup.

- within a particular range - which you can control from the principal switch also.

This is a very high-level explanation. I encourage you to review the SANOS documentation for more details.

Thanks

Carlos Gonzalez

SAN Test Lab - RTP

DCBU Customer Operations Group

Community Member

Re: difference between switch DID and VSAN DID

I think that we need to go a bit further into why you would want to set static Domain ID's . Basically after having a problem with automatic and static Domain ID assignments (through my own stupidity I might add), I would be happy to let the principal switch assign the ID's. However, as we all know, AIX and HP-UX systems don't like the Domain ID to change. If like me, in a prodominately Solaris shop with some Windows and an ever growing Linux presense, I doubt there is a need to worry about the Domain ID's.

One thing that you said was that the ID can be the same for all VSAN's. I am not sure that this can happen and to be honest, when looking at my Solaris host, I can tell which (V)SAN or switch the HBA belongs to from the Domain ID.

Before I started, a contractor put in two Qlogic switches for a high end host. They did a pretty ordinary job and were paid big bucks for it. Both switches had the same Domain number (they were not connected) and they created only one zone per switch with six HBA's (initators) and six storage devices (targets) in the zone. I could not tell which switch provided the LUN's at a quick glance. Each zone was called zone_1 or something similiar which is very helpful to say the least.

All I can say is that we were lucky not to have had a major problem with a malfunctioning HBA.

Stephen

208
Views
4
Helpful
3
Replies
CreatePlease to create content