Brocade Fibre Channel Networking Community

Expand all | Collapse all

Conditions required to configure insistent id

  • 1.  Conditions required to configure insistent id

    Posted 09-22-2014 12:36 PM

    Hi all,

    I'm toiling a bit with setting the IDID on some of my in-service switches. We had an issue during upgrade to FOS 7.1.1c and one of our fabric director switches segmented as a result. I got that sorted by clearing the configs and the director joined the domain again. The problem is we now have lots of HP C7000 interconnect FC switches hooked up to the directors (there's 4 in total, fabA and fabB at two sites) and they didn't have their IDID set (yes I know) anyway...the question is, do both interconnects in each chassis need to be disabled and configured for IDID at the same time? I tried doing one then the other but even though they both came up with the same DID the logs on one of them indicated that there was an IDID problem.

    Bearing in mind that there's loads of live clusters hanging off these I'm hoping the resolution is "environment friendly" any suggestions welcomed.




  • 2.  Re: Conditions required to configure insistent id

    Posted 09-22-2014 08:46 PM

    Usually Insistent Doamin ID is used into FICON environment which is mandatory.


    what is the reason you whant to use IDID ?


    segmented issue can be caused for diverse reason, i.e. wrong or different port Settings, incorrect Domain ID, mismatch config  and much more.


    You should post a bit more info


  • 3.  Re: Conditions required to configure insistent id

    Posted 09-23-2014 04:58 AM
    setting the idid requires switchdisable, which is not really "environment friendly" to me. anyway, if you'd do that, you'll end up managing lots of independent switches, and you'll have to assign all of them consistently different dids.
    to me, the better solution would be turn all of these "blady" switches into access gateways. after that, you'll never have any zoning segmentations and did conflicts, because all of this will only be managed inside your core switches.

  • 4.  Re: Conditions required to configure insistent id

    Posted 09-24-2014 01:15 AM

    Thanks for the reply guys, yes, I agree about the complexity of managing lots of individual switches, I'm working on a configuration which was dictated from another authority so I'm kind of stuck with it. I thought the DID was a concept which applied to all fabric types as a means of good management but I've noticed that two interconnect pair switches can work quite happily with different what's the big deal?

    I believe our director switch (1 of 2 in same fabric) segmented because IDID was set to 1 when the domain was manually changed to use DID 2.......I'm not 100% sure though as a config clearout worked and it joined the fabric straight after that.

    I'm left with 80% of interconnect switches with matching  pair DIDs and 20% with different DIDs !




  • 5.  Re: Conditions required to configure insistent id

    Posted 09-24-2014 01:28 AM



    you post is most confused.


    Both IDID and DID are TWO Different things


    IDID = Insistent Domain ID, is a configuration Settings


    DID = Domain ID, is a Switch Domain ID which must be set as unique ID when more Switch formed a Fabric - ISL -


    in feew word, each Switch in the Fabric must have Unique DID = Domain ID.


    In summary, IDID have nothing to do with DID Address/Number


  • 6.  Re: Conditions required to configure insistent id

    Posted 09-24-2014 08:15 AM

    Yes I know they are 2 different things, I believe that the IDID is set so that the switch always tries to use the DID it was configured with, so that when there is an event which sees the switches reboot they will always have the same DID as they did before the reboot. Is that a correct assumption?


  • 7.  Re: Conditions required to configure insistent id

    Posted 09-26-2014 01:31 AM

    almost. if idid is not set, did may change (on ANY switch in a fabric not having idid) during any fabric rebuild. fabric rebuild happens each time when e-port appears/disappears in the fabric, meaning that did(s) may change even when no switches are rebooting. i'm not 100% sure, i just don't have in fact any experience working without idid. (although i'm working with brocade san since '99)

    since you say the workaround was to clear the config, the issue you could've hit is as follows, and most likely it is not related to idid/did conflict.

    1) one of the "blady" switches had a reboot because of ... something, maybe blade chassis maintenance/management, firmware upgrade, etc... etc... so it was temporarily disconnected from the rest of the san

    2) in the meantime, zoning modification was introduced in the rest of the san

    3) when the victim switch came up, it's zoning config didn't match zoning config in the rest of the san and unlucky switch was rejected to join the fabric

    4) you cleared the config on the unlucky switch and thus alowed the fabric to upload up to date fabric wide config into the "brand new" switch and accept it to the fabric


    i'm not 100% this is your exact case, but this scenario is very likely anyway.


  • 8.  Re: Conditions required to configure insistent id

    Posted 09-26-2014 02:00 AM



    -->>Is that a correct assumption?


    I've reboted in 16+ years since I work with Brocade Plattforms, Thousend of Switches and Fabric , and all this Switches in the Fabric mantain the Assigned Domain ID.

    You can set IDID, but is not mandatory, excepted as mentioned in my preview post in a FICON Environments, or i.e. in some other circumstance when TI is configured.


    Please refer FOS Admin guide for some other details.




  • 9.  Re: Conditions required to configure insistent id

    Posted 09-26-2014 02:27 AM
    right! that's why i said the issue is not likely to be related to did/idid conflict! especially bearing in mind the workaround that cleared the issue!

  • 10.  Re: Conditions required to configure insistent id

    Posted 09-26-2014 03:06 AM

    Thanks for the responses for thought. I think what we had was segmentation because a chassis director was rebooted and hit a domain id issue (as I said before it had been configured to use a different DID from 1 which it had before, I believe it's a good idea to leave DID 1 unreserved in case there is another switch issue which would try to claim as default) the director DID was altered one more time and after reboot that is when it segmented. All of this occurred during a FOS 7.1.1c upgrade. So the moral of the story is take your time during upgrades and don't let the business pressure you into doing it all quickly!