IVR Zoneset activation

Hello!
I have a working (activated) IVR zoneset in which i want to add next zone and i have three questions.
1. Do i have to activate this zoneset when i add new zone?
2. Do i have to make changes on all ivr enabled switches?
3. Is it possible that this modification will stop the traffic in SAN?
Thx for your response.
Best Regards.

1) yes, you have to add new zone to active zone set and activate, just like you do when adding zones to regular zonesets
2) if IVR distribution is enabled, no
3) if you are not messing with existing zones then no

Similar Messages

  • IVR zoneset activation stuck in SAN-OS 3.3

    After trying to activate a zoneset we keep seeing the following log messages endlessly repeating:
    2012 May  4 02:01:45 mds209017901-f1 %ZONE-2-ZS_CHANGE_ACA_FAILED: %$VSAN 265%$ ACA failed : domain 0x63 returns FABRIC_CHANG
    ING
    2012 May  4 02:01:45 mds209017901-f1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED: %$VSAN 265%$ Activation failed
    2012 May  4 02:01:45 mds209017901-f1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED_RESN_DOM: %$VSAN 265%$ Activation failed : reason Fa
    bric changing domain 99
    2012 May  4 02:01:45 mds209017901-f1 %IVR-5-IVZS_ACTIVATION_RETRYING: Inter-VSAN zoneset activation did not go through becaus
    e of Fabric changing, retrying in VSAN 265 after 15 seconds
    2012 May  4 02:01:45 mds209017901-f1 %IVR-2-IVZS_ACTIVATION_FAILED_RETRYING: Inter-VSAN zoneset activation failed in VSAN 265
    : Fabric changing.retrying after 15 seconds
    also:
    sh ivr internal distribution
    Distribution internal information
    lock state 1
    locked by  admin 00:00:00:00:00:00:00:00
    opened : TRUE
    activate_or_deactivate : activation
    force_activate : FALSE
    initiator : TRUE
    implicit_commit : FALSE
    topology activate: FALSE
    msghandle : 1456850992
    status : 0
    zoneset_name : ivr_zoneset-br2
    Ditrib fsm  Current State : IVR_ZONE_DISTRIB_ST_ACTIVATING
       Number of zoneset in pending database : 4
       Number of zones in pending database   : 410
       Number of members in pending database : 2446 sh ivr internal distribution
    Distribution internal information
    lock state 1
    locked by  admin 00:00:00:00:00:00:00:00
    opened : TRUE
    activate_or_deactivate : activation
    force_activate : FALSE
    initiator : TRUE
    implicit_commit : FALSE
    topology activate: FALSE
    msghandle : 1456850992
    status : 0
    zoneset_name : ivr_zoneset-br2
    Ditrib fsm  Current State : IVR_ZONE_DISTRIB_ST_ACTIVATING
       Number of zoneset in pending database : 4
       Number of zones in pending database   : 410
       Number of members in pending database : 2446
    I am not at all an expert with SAN, but have been asked to help if possible.  Can anyone provide any way to unwind this stuck activation?  Not sure if clearing the ivr session will help or not and don't want to try it without knowing if it will cause the situation to get worse.  Any suggestions are appreciated.
    thanks
    P

    OK here are the outputs from "show zone internal vsan 265" from both switches (domain 6 & domain 99)
    domain6:
    mds209017901-f1#  show zone internal vsan 265
    VSAN: 265 default-zone: deny(rw) distribute: full
        E_D_TOV: 2000 R_A_TOV: 10000 D_S_TOV: 5000 F_S_TOV: 5000 F_D_TOV: 2000
        Interop: default IOD: disable bcast: disable dflt-bcast: disable dflt-qos: 0
        DBLock:-(F count:0) Ifindex Table Size: 230 Transit Frame Index: 0
        Total Transit Frame Count: 74 Transit Discard Count: 0
    Full Database Counters :
        Zonesets: 1 Zones: 1 Huge id zones: 0
        Read-only Zones: 0 QoS Zones: 0 Broadcast Zones: 0
        Aliases: 0 Attribute-groups: 0
        Members: 4 LUN Members: 0 DDAS Members: 0
        Adv Zoning3 Members(IPv4 + dom-If): 0 IPv6 Members: 0
    Session Database Counters (diff) :
        Zonesets: 0 Zones: 0
        Aliases: 0 Attribute-groups: 0
        Members: 0 LUN Members: 0 DDAS Members: 0
    Active Database Counters :
        Zonesets: 1 Zones: 403 Huge id zones: 0
        Read-only Zones: 0 QoS Zones: 0 Broadcast Zones: 0
        Members: 421 LUN Members: 0 DDAS Members: 0
        Adv Zoning3 Members(IPv4 + dom-If): 0 IPv6 Members: 0
    Session Active Database Counters (diff) :
        Zones: 0 Members: 0 LUN Members: 0 DDAS Members: 0
    License Info: 0x0
    Full Zoning Database :
        DB size: 196 bytes
        Zonesets:1  Zones:1 Aliases: 0
    Active Zoning Database :
        DB size: 41812 bytes
        Name: production_storage  Zonesets:1  Zones:403
    TCAM Info :
        cur_seq_num : 19742,  state : 0, def_enum : 0
        gen state : 0,  cur_num_dids : 0 total_num_dids : 0
        num tcam q : 0 num pending q : 0
    Change protocol info :
        local domain id = 6,   ACA by 0xff
        State =       Idle,  reply_cnt = 1, req_sent_cnt = 1, req_pending = 0
        Remote domains :
            2(0x2)
            10(0xa)
            11(0xb)
            16(0x10)
            20(0x14)
            23(0x17)
            27(0x1b)
            36(0x24)
            73(0x49)
            82(0x52)
            96(0x60)
            97(0x61)
            99(0x63) [21:09:00:0d:ec:3f:37:41]
            102(0x66)
            103(0x67)
            108(0x6c)
            111(0x6f)
            116(0x74)
            117(0x75)
            129(0x81)
            136(0x88)
            138(0x8a)
            150(0x96)
            161(0xa1)
            186(0xba)
            223(0xdf)
            228(0xe4)
            15(0xf)
            55(0x37)
            26(0x1a)
            128(0x80)
            91(0x5b)
        Status : Received RJT from dom 99, RCA Sent!
    Merge proto info :
        i/f port-channel 5
           State = Idle       | notify = 0x7 | - -
    domain 99:
    mds209817515-f1# show zone internal vsan 265
    VSAN: 265 default-zone: deny(rw) distribute: active only
        E_D_TOV: 2000 R_A_TOV: 10000 D_S_TOV: 5000 F_S_TOV: 5000 F_D_TOV: 2000
        Interop: default IOD: disable bcast: disable dflt-bcast: disable dflt-qos: 0
        DBLock:-(F count:0) Ifindex Table Size: 230 Transit Frame Index: 0
        Total Transit Frame Count: 154 Transit Discard Count: 11
    Full Database Counters :
        Zonesets: 1 Zones: 1 Huge id zones: 0
        Read-only Zones: 0 QoS Zones: 0 Broadcast Zones: 0
        Aliases: 0 Attribute-groups: 0
        Members: 4 LUN Members: 0 DDAS Members: 0
        Adv Zoning3 Members(IPv4 + dom-If): 0 IPv6 Members: 0
    Session Database Counters (diff) :
        Zonesets: 0 Zones: 0
        Aliases: 0 Attribute-groups: 0
        Members: 0 LUN Members: 0 DDAS Members: 0
    Active Database Counters :
        Zonesets: 1 Zones: 403 Huge id zones: 0
        Read-only Zones: 0 QoS Zones: 0 Broadcast Zones: 0
        Members: 421 LUN Members: 0 DDAS Members: 0
        Adv Zoning3 Members(IPv4 + dom-If): 0 IPv6 Members: 0
    Session Active Database Counters (diff) :
        Zones: 0 Members: 0 LUN Members: 0 DDAS Members: 0
    License Info: 0x0
    Full Zoning Database :
        DB size: 196 bytes
        Zonesets:1  Zones:1 Aliases: 0
    Active Zoning Database :
        DB size: 41812 bytes
        Name: production_storage  Zonesets:1  Zones:403
    TCAM Info :
        cur_seq_num : 184366,  state : 0, def_enum : 0
        gen state : 0,  cur_num_dids : 0 total_num_dids : 0
        num tcam q : 0 num pending q : 0
    Change protocol info :
        local domain id = 99,   ACA by 0xff
        State =       Idle,  reply_cnt = 0, req_sent_cnt = 0, req_pending = 0
        Remote domains :
            6(0x6) [21:09:00:0d:ec:11:c3:01]
            23(0x17)
            186(0xba)
            96(0x60)
            150(0x96)
            97(0x61)
            138(0x8a)
            82(0x52)
            16(0x10)
            161(0xa1)
            129(0x81)
            116(0x74)
            20(0x14)
            11(0xb)
            27(0x1b)
            111(0x6f)
            36(0x24)
            2(0x2)
            117(0x75)
            73(0x49)
            102(0x66)
            136(0x88)
            10(0xa)
            223(0xdf)
            108(0x6c)
            103(0x67)
            15(0xf)
            55(0x37)
            26(0x1a)
            128(0x80)
            91(0x5b)
        Status : Domains mismatch, ACA from dom 6 Rejected!
    Merge proto info :
        i/f port-channel 1
           State = Idle       | notify = 0x7 | - -
    thanks,
    peter

  • Zoneset activation failed

    I have a problem with a failed zoneset activation. It failed for whatever reason, but now it keeps retrying every 30 seconds. How do I stop abort it completely?
    9513 Core and Edge directors running 3.0(2a). I have a case open through our vendor, but its been over a week with little response.
    Thanks,
    -Brooks
    2007 Sep 21 16:58:11 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED: %$VSAN 30%$ Activation failed
    2007 Sep 21 16:58:11 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED_RESN_DOM: %$VSAN 30%$ Activation failed : reason Fabric changing domain 117
    2007 Sep 21 16:58:26 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED: %$VSAN 30%$ Activation failed
    2007 Sep 21 16:58:26 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED_RESN_DOM: %$VSAN 30%$ Activation failed : reason Fabric changing domain 103
    2007 Sep 21 16:58:41 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED: %$VSAN 30%$ Activation failed
    2007 Sep 21 16:58:41 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED_RESN_DOM: %$VSAN 30%$ Activation failed : reason Fabric changing domain 117
    2007 Sep 21 16:58:56 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED: %$VSAN 30%$ Activation failed
    2007 Sep 21 16:58:56 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED_RESN_DOM: %$VSAN 30%$ Activation failed : reason Fabric changing domain 103
    2007 Sep 21 16:59:11 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED: %$VSAN 30%$ Activation failed
    2007 Sep 21 16:59:11 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED_RESN_DOM: %$VSAN 30%$ Activation failed : reason Fabric changing domain 117
    2007 Sep 21 16:59:26 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED: %$VSAN 30%$ Activation failed
    2007 Sep 21 16:59:26 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED_RESN_DOM: %$VSAN 30%$ Activation failed : reason Fabric changing domain 103
    2007 Sep 21 16:59:41 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED: %$VSAN 30%$ Activation failed
    2007 Sep 21 16:59:41 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED_RESN_DOM: %$VSAN 30%$ Activation failed : reason Fabric changing domain 117
    2007 Sep 21 16:59:56 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED: %$VSAN 30%$ Activation failed
    2007 Sep 21 16:59:56 ITDCHLSAN-9513-A-E-1 %ZONE-2-ZS_CHANGE_ACTIVATION_FAILED_RESN_DOM: %$VSAN 30%$ Activation failed : reason Fabric changing domain 117

    Workaround is to shut/no shut the ISL port. This is related to bug CSCeh93645

  • How can I enable IVR on FCIP environement

    Dear All,
    I will do following procedures to enable IVR on FCIP environment.
    1. 'show wwn switch' command to record both of local and remote Switches' WWN.
    2. set unique domain ID required if SAN-OS less than Release 2.1.
    a. fcdomain domain domain_number static vasn vasn_number
    b. config t; vsan database; vsan vsan_number suspend; no vsan suspend; end
    3. enable
    a. config t
    b. ivr enable
    4. config IVR-enable border switches.
    a. ivr vsan-topology database
    b. autonomous-fabric-id 1 switch-wwn 20:00:00:0d:ec:09:8d:00 vsan-ranges 10,99
    c. autonomous-fabric-id 1 swtich-wwn 20:00:00:0d:ec:0c:e6:40 vsan-ranges 20,99
    5. Zoning
    a. ivr zone name IVRZone1
    b. member pwwn PSPA3 (vsan ?)
    c. member pwwn PSPB3
    d. exit
    e. ivr zoneset name IVRZoneSet1
    f. member IVRZone1
    g. exit
    h. ivr zoneset activate name IVRZoneSet1 force
    6. Verify
    a. exit
    b. show ivr vsan-topology
    c. show ivr zoneset active
    e. show ivr
    Could you advice me the above prcedures need to run only one switch or need to run both of swtiches?
    Thank you,
    Dennis

    Try:
    http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide_chapter09186a008022a7f8.html

  • Configuring Persistent FC IDs for IVR

    Has anybody configured this for  IVR ? I use persistent FC IDs for my regular VSANs because i have a  couple of AIX boxes. I will also have a couple of them access storage  via IVR, dynamic tracking is not enabled on the host so i am wondering  if i should enabled persistent fc id for IVR ?
    Thanks

    Sure
    Assuming a single MDS using vsan 1 and vsan 2, both vsans using domain ID 0x12.
    HBA is pwwn1, Storage is pwwn2
    config term
    This is to export the storage array that resides in vsan 2, into vsan 1 as fcid 0xaa3344
    ivr fcdomain database autonomous-fabric-num 1 vsan 1
    native-autonomous-fabric-num 1 native-vsan 2 domain 0xAA
      pwwn pwwn2 fcid 0xAA3344
    This is to export the hba that resides in vsan 1, into vsan 2 as fcid 0x232323
    ivr fcdomain database autonomous-fabric-num 1 vsan 2
    native-autonomous-fabric-num  1 native-vsan 1 domain 0x23
      pwwn pwwn1 fcid 0x232323
    If there are multiple MDS in the IVR topology, these entries would need to be included in each of the IVR enabled MDS.
    You can use CFS to form peers amongst the IVR enabled switches and then use the 'ivr commit' to propagate the config command to the other MDS.
    In this example, domain ID 0x23 can not already exist in vsan 2, nor can any switch join vsan 2 using domain ID 0x23.  The same is true for vsan 1 and domain 0xAA.
    Lastly, this example does reflect overlapping vsan IDs.  That is why both vsan 1 and 2 are in autonomous-fabric (AFID).  Had there been multiple MDS, and overlapping VSAN numbers (IDs), then to use IVR, those overlapping VSANs must be configured in different AFIDs.  Basically you can have a device in vsan 1, domain ID 0x12 and using IVR NAT have it zoned with another device, in another MDS, in vsan 1, using domain ID 0x12, as long as the vsans are in different AFIDs.
    The intent is not to design SANs this way, but if you have case where 2 existing SANs need to have some devices communicate, and neither SAN can change the existing vsan numbers and domain IDs, there is a way to connect the 2 devices and let them remain in the same vsan keeping the same FCID.
    I would always recommend putting these static entries in place, before creating and activating the IVR zoneset.  I would not recommend adding in the static entries (unless they matched what was currently in use) , as I am not sure if the MDS would log out the devices to enforce the new static mappings.  It may only use the database when the zoneset is activated, or it could put it into effect immediately.
    -now you know what I know
      Mike

  • IVR-NAT mode migration

    Hello folks,
    i am preparing to upgrade my MDS 9513 (rev 2) and MDS 9222i to 5.2.6a code. Looking at the release notes for 5.2.x i see that i will first need to upgrade to 5.0.x and then to 5.2.x. Another caveat that i see is that we currently use IVR without IVR-NAT and this configuration is no longer support in 5.2.x. Release notes provide the commands to migrate to IVR-NAT mode that seem to be relatively simple. I understand that this will require an outage.
    Has anyone done this recently, any pitfalls ? Did your IVR topology, zones stay intact ?
    Thanks

    Hello Dynamoxxx,
    - Yes, many customer did the migration from IVR NON-NAT to IVR NAT without issue. There is disruption for IVR zone only, since the active zoneset need to be deactivated.
    - Confirmed, IVR topology and zones stay intact after this process.
    To migrate to IVR-NAT mode, follow these steps:
    1. Stop or divert all applications on servers that depend on IVR.
    –If CFS distribution is not enabled for IVR, then perform steps 2 through 4 on all switches where IVR is enabled.
    –If CFS distribution is enabled for IVR, then enter the ivr commit command following step 2, step 3, and step 4 to distribute the changes to other switches.
    2. Deactivate the IVR zone set by entering the no ivr zoneset activate command.
    3. Enable IVR NAT by entering the ivr nat command.
    4. Activate the IVR zone set by entering the ivr zoneset activate command.
    5. Start or reestablish all application that were stopped in step 1.
    The network can now run in IVR-NAT mode.
    Also, you can use Fabric Manager GUI to enable IVR-NAT as follow:
    1.  SAN --- > Fabric xx --- > All VSANs --- > IVR --- > Deactivate Zoneset
    2.  SAN --- > Fabric xx --- > All VSANs --- > IVR --- > action --- > Check box "Enable IVR NAT" --- > Click enable button --- > Click CFS
    3.   Zone --- > right click IVR --- > edit Local Full Zone Database --- > Select zoneset --- > Activate
    Hope this help

  • Device Alias not showing up in device manager

    Folks,
               I did create the device alias database and I can see the device aliases show up with I type show zoneset active in cli. But when I go to the fabric manager I am unable to see the devices aliases only the actual pwwn shows up. Do I have to enable anything special in the device manager for it to show up.
    Thanks

    Hi,
    Try this...
    In Fabric Manager  File > Open > Fabrics
    Verify "Use FC Alias" is not selected.
    Regards,
    David

  • Ask the Expert: Cisco UCS Troubleshooting Boot from SAN with FC and iSCSI

    Welcome to this Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about Cisco UCS Troubleshooting Boot from SAN with FC and iSCSI with Vishal Mehta and Manuel Velasco.
    The current industry trend is to use SAN (FC/FCoE/iSCSI) for booting operating systems instead of using local storage.
    Boot from SAN offers many benefits, including:
    Server without local storage can run cooler and use the extra space for other components.
    Redeployment of servers caused by hardware failures becomes easier with boot from SAN servers.
    SAN storage allows the administrator to use storage more efficiently.
    Boot from SAN offers reliability because the user can access the boot disk through multiple paths, which protects the disk from being a single point of failure.
    Cisco UCS takes away much of the complexity with its service profiles and associated boot policies to make boot from SAN deployment an easy task.
    Vishal Mehta is a customer support engineer for Cisco’s Data Center Server Virtualization TAC team based in San Jose, California. He has been working in the TAC for the past three years with a primary focus on data center technologies such as Cisco Nexus 5000, Cisco UCS, Cisco Nexus 1000v, and virtualization. He has presented at Cisco Live in Orlando 2013 and will present at Cisco Live Milan 2014 (BRKCOM-3003, BRKDCT-3444, and LABDCT-2333). He holds a master’s degree from Rutgers University in electrical and computer engineering and has CCIE certification (number 37139) in routing and switching and service provider.
    Manuel Velasco is a customer support engineer for Cisco’s Data Center Server Virtualization TAC team based in San Jose, California. He has been working in the TAC for the past three years with a primary focus on data center technologies such as Cisco UCS, Cisco Nexus 1000v, and virtualization. Manuel holds a master’s degree in electrical engineering from California Polytechnic State University (Cal Poly) and VMware VCP and CCNA certifications.
    Remember to use the rating system to let Vishal and Manuel know if you have received an adequate response. 
    Because of the volume expected during this event, our experts might not be able to answer every question. Remember that you can continue the conversation in the Data Center community, under subcommunity Unified Computing, shortly after the event. This event lasts through April 25, 2014. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

    Hello Evan
    Thank you for asking this question. Most common TAC cases that we have seen on Boot-from-SAN failures are due to misconfiguration.
    So our methodology is to verify configuration and troubleshoot from server to storage switches to storage array.
    Before diving into troubleshooting, make sure there is clear understanding of this topology. This is very vital with any troubleshooting scenario. Know what devices you have and how they are connected, how many paths are connected, Switch/NPV mode and so on.
    Always try to troubleshoot one path at a time and verify that the setup is in complaint with the SW/HW interop matrix tested by Cisco.
    Step 1: Check at server
    a. make sure to have uniform firmware version across all components of UCS
    b. Verify if VSAN is created and FC uplinks are configured correctly. VSANs/FCoE-vlan should be unique per fabric
    c. Verify at service profile level for configuration of vHBAs - vHBA per Fabric should have unique VSAN number
    Note down the WWPN of your vhba. This will be needed in step 2 for zoning on the SAN switch and step 3 for LUN masking on the storage array.
    d. verify if Boot Policy of the service profile is configured to Boot From SAN - the Boot Order and its parameters such as Lun ID and WWN are extremely important
    e. finally at UCS CLI - verify the flogi of vHBAs (for NPV mode, command is (from nxos) – show npv flogi-table)
    Step 2: Check at Storage Switch
    a. Verify the mode (by default UCS is in FC end-host mode, so storage switch has to be in NPIV mode; unless UCS is in FC Switch mode)
    b. Verify the switch port connecting to UCS is UP as an F-Port and is configured for correct VSAN
    c. Check if both the initiator (Server) and the target (Storage) are logged into the fabric switch (command for MDS/N5k - show flogi database vsan X)
    d. Once confirmed that initiator and target devices are logged into the fabric, query the name server to see if they have registered themselves correctly. (command - show fcns database vsan X)
    e. Most important configuration to check on Storage Switch is the zoning
    Zoning is basically access control for our initiator to  targets. Most common design is to configure one zone per initiator and target.
    Zoning will require you to configure a zone, put that zone into your current zonset, then ACTIVATE it. (command - show zoneset active vsan X)
    Step 3: Check at Storage Array
    When the Storage array logs into the SAN fabric, it queries the name server to see which devices it can communicate.
    LUN masking is crucial step on Storage Array which gives particular host (server) access to specific LUN
    Assuming that both the storage and initiator have FLOGI’d into the fabric and the zoning is correct (as per Step 1 & 2)
    Following needs to be verified at Storage Array level
    a. Are the wwpn of the initiators (vhba of the hosts) visible on the storage array?
    b. If above is yes then Is LUN Masking applied?
    c. What LUN number is presented to the host - this is the number that we see in Lun ID on the 'Boot Order' of Step 1
    Below document has details and troubleshooting outputs:
    http://www.cisco.com/c/en/us/support/docs/servers-unified-computing/ucs-b-series-blade-servers/115764-ucs-san-tshoot-00.html
    Hope this answers your question.
    Thanks,
    Vishal 

  • How to remove switches from a fabric.

    We have a couple of MDS9120's and a SUP1 9509 in our fabric that we want to retire.   I'm pretty sure that I don't want to just shut down these switches, unplug the cables and call it good.   Also the 9509 is the principal for two of our larger VSAN's and one of the 9120's is a principal for another that we are still using.  Also, this same used to have an IVR zoneset which I think is gone, at least I don't see it when I look at IVR.  Current all the switches in the fabric are running 3.31c code.  Since we are planning moving to the 4.x we want remove these since they will not be supported.
    So, what is the procedure to make another switch the principal of a VSAN, and once a switch is no longer a principal what is the procedure for cleanly removing it from the fabric?     If someone has some insights or can point to me to documentation that covers this, it would be greatly appreciated.
    Thanks,
    Jeff Blomendahl
    University of Kansas Medical Center

    In case anyone is still interested,  I opened a TAC case on this because I could see that the information was all out there, but I wanted to make sure that I didn't miss anything that would bite me.  It turnes out that it wasn't that big of a deal if you do it correctly.
    To remove a switch that is the principal for a VSAN, as was mention earlier in this thread, you need to give it a lower priority and give the switch that you want to make the principal the highest priority.  In our case, the "old" switch had a priority of 1 for 3 of our VSANs, so I changed it to the default of 128 and on the switch that was to be the "new" principal, the priority was set to 1.  Assuming that you are in config mode on the switch, the commands from the CLI looked like this:
    On the "old" switch:
    fcdomain priority 128 vsan xx   (xx being the number of the VSAN, this sets the switch priority to the default of 128)
    fcdomain restart xx     (again, xx being the number of the VSAN,  This will non-disruptively restart the vsan on the switch and change the priority.  Be aware that if you are using static domain ID's the restart may be disruptive on the switch, check the documention for more on this)
    On the "new" switch:
    fcdomain priority 1 vsan xx   (xx being the number of the VSAN, this sets the switch priority to the highest priority, 1)
    fcdomain restart xx     (again, xx being the number of the VSAN,  This will non-disruptively restart the vsan on the switch and change the priority.  Be aware that if you are using static domain ID's the restart may be disruptive on the switch, check the documention for more on this)
    Do this for every VSAN that the "old" switch is the principal and also on the "new" switch that is to be the principal.  From what I saw in the Domain Manager this will change the priority but won't necessarily change the principal assignment.  At this point the "old" switch is ready to be removed from the fabric.  Obviously, since this switch was the principal, you'll want to make sure that all of the zoneset information for those zones has been replicated to the other switches in the fabric, particularly to the switch that is to become the new principal.  Other than an ISL to the rest of the fabric and the connections to the management ports, there was nothing connected to the "old" switch. 
    At this point you can shutdown the ISL to the "old" switch from the switch that is on the other end of the ISL.  At this point you will see the fabric segment (as viewed from Fabric Manager)  At this point, I unplugged the management cables from the "old" switch, since I didn't want it talking to the Fabric Manager anymore.  I purged the switch and after about 5 or 10 minutes the segmentation went away and the fabric returned to normal, less the "old" switch.    There was no disruption to any of the 240+ hosts that were on the affected VSANs and the switch with the priority of 1 became the principal just like it was supposed to.
    I think that once the ISL has been brought down, you want to take the switch off of the network or shut it down so that it can't continue to talk to the FM.  If this isn't done, FM will see that there are VSANs on that switch that are disconnected from the rest of the fabric and will show that the fabric is segmented.  I went through this procedure successfully on a SUP1 MDS 9509 and a MDS 9120 that were running 3.3.1 code.  One thing that did make my heart stop for a second was when I went to look at the zonesets after the segmentation cleared up.  The zonesets were there, but the zones were gone!   Since my pager wasn't vibrating out of the holster, I reasoned that the zones were still there.   A quick look at the configs on the switches confirmed this.  What had happened, was that the switch that I removed was the seed switch for FM when it discovered the fabric.  To correct this I restarted FM and rediscovered the fabric using the "new" principal switch as the seed switch, and all of the zones were back were they were supposed to be. 
    Just for your piece of mind (read CYA), I recommend opening a TAC case just to have them look over your configs and make any recommendations.  In our case, we had to remove IVR from one of our switches and the engineer pointed out a bug that can occur when removing IVR, and a work around for this bug.
    Sorry for the long post, but I hope that this information is helpful to someone else that has to do this.
    Jeff Blomendahl
    Enterprise Systems Engineer
    University of Kansas Medical Center

  • FCIP interface stuck at initializing on 9216i v2.1a (vsan segmented)

    Following the instructions in both the config guide and troubleshooting guide to configure the FCIP profile and interface, my fcip2 interface status is stuck at initializing. Looking in FM events tab, I can see that the 9216i's are cycling between these states: vsan merged; N_Port unmanageble; vsan segmented and N_Port Up. show fcdom domainlist on the higher priority switch shows it flip-flopping between [local] and principal] [local] states. Using show zoneset active, I can see the zoneset being transfered over to the 2nd switch. Despite all this, the fcip interface does not stay up. Thanks for helping.

    Just going from your info, it sounds like the interface comes up for a little bit of time. More than likely then, the issue is MTU. You have an MTU configured larger than somewhere in the network can handle it. If you get the show log output and it shows alot of TCP retransmissions, this is the problem.

  • Troubleshoot zoning in server 2008 r2

    So we are replacing our McDatas with MDS 9124s.
    I think I have a good grasp on what and how to do what I have to do.  We have two storage controllers (netapp.. one for sata and one for sas). 2 sql servers (win 2003 and 2008r2) Two ESX servers and an backup server with 2003 and a dual drive ibm library for ndmp backups.
    It appears that I cant get the server 2008r2 server to see the drives properly on the Cisco switches. Everything else appears to be working (none of the other servers are complaining) I have double/triple checked the zone config for that server on both Cisco switches. I have installed sansurfer and it shows connectivity. Storage Explorer shows connectivity to both switches as well.
    I just dont get it.. it works fine with mcdata but not with the Ciscos..
    I went through (several of many) troubleshooting guides from Cisco but nothing...
    Any help would be really really really apprecitated.

    Andrew
    A bit more info is needed...
    Can you show us the output of "sh zoneset active vsan {vsan_everything_is_in}"
    Also let us know what devices are the Win server and which are the tape drives (if it's not obvious by thr names in the sh zoneset)
    Steven

  • Nozoneset Help please

    There are a few zones and zonesets that i have not created, but they still show in the sh run, and they show as active.
    When I try to delete those zones or zonesets i get an error "Zone/zoneset not present"
    What are these and how you clean them?
    Thanks

    G'day,
    First of all you need to ensure that nothing is using the zoneset that you are about to delete. If you are sure you dont want the zones/zonesets running you can simply deactivate the running zoneset.
    /* determine the running zoneset name */
    switch# sh zoneset active vsan 100 (or whatever your vsan number is)
    /* enter config mode */
    switch# config
    /* deactivate the running zoneset */
    switch(config)# no zoneset activate name my_zoneset vsan 100
    Cheers
    Andrew

  • Adding a 9124e to an existing 9509 Switch

    Guys:
    Config info:
    I have a HP C class blade enclosure, with 2 new 9124e's in it. I need to activate it,and figure on doing the following:
    Define 2 T ports on the 9124e, and connect them, to 2 Fx ports on the 9509.(1 9124 to each 9509 for redundancy)
    Here are my questions:
    1) I am thinking that once the ports are connected and activated, the 9509 will propogate the existing config over to the 9124e, and I will modify the zone defs copied into the 9124e, and then activate the zoneset in the 9124e. Is that correct?
    2) What happens when I activate the zone (zone 10 copied from 9509-1) in the new 9124e switch? Will it activate the zone in the 9509 also?
    3) Since the 9124e has no Flash card, do I make the changes, copy the config to startup-config on the 9124e? will the changes be propogated to the 9509?
    4) If the changes are copied to the 9509, do I login to the 9509, and copy the active config to the 9509's startup-config and flash drive?
    Are there any other issues I am missing? Sorry for the questions, but any info will be a HUGE help.
    Thanks
    SAN Man

    You can connect 9124 to 9509, though there is principal switch selection, the principal switch plays a role only during adding different switches and assigning or managing the domain ids. If you give static domain ids (different ones for each switch you add), then role of principal switch is very less.
    It is better to have username/passwords (snmp/cli) synced across all the switches, so that from FM you can manage all switches in the fabric.
    Having different username/password does not affect FC traffic and you could still activate a zoneset on a vsan from a switch you have permission, the zoneset active/full (based on config) will get distributed to multiple switches.
    If the ISL is broken, then switches will operate standalone, providing access to locally connected devices.
    http://www.cisco.com/en/US/docs/storage/san_switches/mds9000/sw/rel_3_x/troubleshooting/guide/ts_zones.html
    http://www.cisco.com/en/US/docs/storage/san_switches/mds9000/sw/rel_3_x/troubleshooting/guide/ts_port.html

  • CUE License Help

    Hi,
    I added 2 vm ports license to the CUE8.5 to make it 4 in total. I activated it and reloaded the CUE. The 'show lice in-use' shows License Count: 4/2.  The 'sh license status application' shows only 2 ports. How can I get 4/4 instead?
    ism-cue# sh licen in-use
    StoreIndex:  1  Feature: VMIVR-VM-MBX                      Version: 1.0
            License Type: Permanent
            License State: Active, In Use
            License Count: 5 /5
            License Priority: Medium
    StoreIndex:  2  Feature: VMIVR-PORT                        Version: 1.0
            License Type: Permanent
            License State: Active, In Use
            License Count: 4 /2
            License Priority: Medium
    ism-cue# sh license status application
    voicemail enabled: 2 ports, 2 sessions, 5 mailboxes
    ivr disabled, ivr session activation count has been set to zero
    ism-cue# sh licen in
    StoreIndex:  1  Feature: VMIVR-VM-MBX                      Version: 1.0
            License Type: Permanent
            License State: Active, In Use
            License Count: 5 /5
            License Priority: Medium
    StoreIndex:  2  Feature: VMIVR-PORT                        Version: 1.0
            License Type: Permanent
            License State: Active, In Use
            License Count: 4 /2
            License Priority: Medium
    ism-cue# sh license status application
    voicemail enabled: 2 ports, 2 sessions, 5 mailboxes
    ivr disabled, ivr session activation count has been set to zero
    Thanks in advance.

    Hi,
    After a couple experiences, I realized that "reload" is not the command to have the new license work, even though the documentation says reload after new lincense installation and activation. I have to "reset" cue, or power cycle the cme to make it work.
    Regards.

  • Migrating between switches

    We have a small SAN based on a 9140 switch. We need to expand and have purchased a 9509. I'd like to connect the switches, migrate the connections in my production VSAN onto the 9509, leave the test VSAN on the 9140, and then disconnect the two switches, creating two fabrics. Is there an easy way to do this? I've tried setting up a trunk between the switches but I think I need to create a common domain; as this is disruptive I want to avoid that if possible.

    Here is what I would suggest. I assume that the 9140 has all active ports in a single VSAN. I would create that same VSAN number in the 9509, and assign it a different Domain ID. Then connect an ISL cable between the 2 devices. If the VSAN comes up on the E or TE port, the active zoneset from the 9140 should show up in the 9509. If the zone members were created by using the device PWWN, then you move devices over at your leisure. Once all devices are migrated, you can disconnect the ISL to the 9140 and do with it what you want.
    In the 9140 to view the current status, here are some commands for the CLI to help you determine what is currently in place.
    show vsan membership (shows which physical ports are in which vsan)
    show flogi database (shows which devices are logged into the 9140)
    show zoneset active vsan x (shows the currently active zoning database for the vsan noted in the command by x)
    Steps to do on the 9509.
    create the vsan
    place the desired number of ports into the vsan
    take these ports out of shutdown mode
    bring up the ISL between the 2 swtiches
    check for the zoneset to show up in the 9509
    Again, if the zone members are PWWN, then you can move the devices at your own pace from the 9140, to the 9509. If the zone members are not by PWWN, then you would need to generate the corresponding zones to maintain connectivity as devices are migrated.
    If the host/storage are dual attached to the 9140, you can make the migration 1 path at a time and incur no down time.
    I hope this helps,
    Mike

Maybe you are looking for