Cisco EMC ViPR – Cisco IVR Cross- Connect Zoning (VPLEX) October 9, 2015 Cisco , Vblock CISCO IVR , CROSS-CONNECT , EMC VPLEX , METRO , VIPR , Zoning Known ViPR&VPLEX Storage Provisioning Issue: The following error may be encountered while provision a shared VPLEX distributed volume to an ESXi Cluster using ViPR v2.x – 2.3: The reason why this issue occurs during a ViPR storage provisioning task with VPLEX is due to the fact that ViPR incorrectly attempts to apply two simultaneous updates to the Cisco MDS IVR database, correctly the MDS database is locked by the first task and the second task times out resulting in a failed ViPR provisioning process. The tasks should be executed in a sequential fashion allowing each task to complete and then commit changes to the IVR database thus removing the lock it held once the commit is successful. Once the database lock is removed then the subsequent task may execute on the database. Workaround: Executing an exclusive storage provisioning order from ViPR catalog for a single ESXi host works perfectly, including automatically
Transcript
Cisco EMC ViPR – Cisco IVR Cross-Connect Zoning (VPLEX) October 9, 2015 Cisco, Vblock CISCO IVR, CROSS-CONNECT, EMC VPLEX, METRO, VIPR, Zoning Known ViPR&VPLEX Storage Provisioning Issue:The following error may be encountered while provision a shared VPLEX distributed volume to an ESXi Cluster using ViPR v2.x – 2.3:
The reason why this issue occurs during a ViPR storage provisioning task with VPLEX is due to the fact that ViPR incorrectly attempts to apply two simultaneous updates to the Cisco MDS IVR database, correctly the MDS database is locked by the first task and the second task times out resulting in a failed ViPR provisioning process. The tasks should be executed in a sequential fashion allowing each task to complete and then commit changes to the IVR database thus removing the lock it held once the commit is successful. Once the database lock is removed then the subsequent task may execute on the database.Workaround:Executing an exclusive storage provisioning order from ViPR catalog for a single ESXi host works perfectly, including automatically creating the required Cross-Connect Zoning, this is due to the fact the single workflow performs MDS IVR database updates sequentially. During the single ESXi host exclusive storage provisioning task ViPR creates the necessary initiators, storage views and IVR Zones (both local and cross-connect zoning) for a single host. BUT performing a shared storage provisioning task to an ESXi Cluster fails in a single catalog order, it will also fail if two exclusive storage provision orders are executed at the same time. In summary the workaround is to execute an exclusive storage provisioning order for each host in the cluster individually one at a time. Once this is complete and each host has a volume presented and VPLEX has the correct initiators and storage views created by ViPR, you may then create a new distributed LUN for the whole ESXi cluster. ViPR simply adds the new
distributed volumes to existing storage views in VPLEX (there is no zoning going on when you run the ddev creation, thus no locking). Once you have a working distributed volume for all of the hosts, you may then remove the exclusive volumes and everything should function accordingly. Ensure to verify that all the required zoning (including IVR Zones) is configured correctly on all switches and the ESXi hosts can see all associated paths.NOTE: ViPR engineering plan to enhance the Zoning workflow with an additional step to obtain/monitor any IVR database locks before proceeding with the IVR zoning operations. This will be targeted for the next ViPR release. I will provide updates to this post in due course.Solution Example:The below diagram depicts the connectivity requirements in order to implement a ViPR storage provisioning solution with a VPLEX Metro configuration using Cross-Connect Zoning:
From the above digram you can see that an ISL is in place for Site-to-Site connectivity, in this example configuration the ISL carries VPLEX-FC-WAN-Replication traffic over VSAN30(Fabric-A) and VSAN31(Fabric-B) -(VPEX FC WAN COM). VSAN30 is stretched between Fabric-A switches on both sites and VSAN31 is stretched between both switches on Fabric-B for Site1&2. VSAN30&31 can be used as transit VSANs for this example IVR configuration.In order for ViPR v2.x to successfully execute the task of automatically creating the required cross-connect zoning the following configuration needs to be in place (as per example diagram above):Site1:Fabric-A, VSAN10: associated interfaces|PC (even ESX hba of site1, VPLEX FE&BE and PC30) added as members to vsan10.Fabric-B, VSAN11: associated interfaces|PC (odd ESX hba of site1, VPLEX FE&BE and PC30)
added as members to vsan11.Site 2:Fabric-A, VSAN20: associated interfaces|PC (even ESX hba of site2, VPLEX FE&BE and PC31) added as members to vsan20.Fabric-B, VSAN21: – associated interfaces|PC (odd ESX hba of site2, VPLEX FE&BE and PC31) added as members to vsan21.Site1 – Site2:Fabric-A: VSAN30 used as a transit vsan over Port-channel 30.Fabric-B: VSAN31 used as a transit vsan over Port-channel 31.A prereq is required in order for ViPR to successfully create the cross-connect zoning automatically as part of the provisioning workflow, the prereq is to manually create an IVR zone on fabric A, connecting vsan 10 and vsan 20 and an IVR zone on Fabric B connecting vsan11 and vsan 21 (example IVR Zones provided below).In the case of ViPR v2.2 an additional prereq task is required and that is to stretch the VSANs between sites, as per this example VSAN20 gets added to switch-A on Site 1 and vice-versa VSAN10 added to switch-A on Site2, repeat same for Fabric-B switches but no local interfaces are assigned to these dummy VSANs, essentially a VSAN20 is created without any member on Switch-A Site1 etc. This is done for all respective VSANs as can be seen in the example configuration provided below. As part of the VSAN stretch ensure to add the allowed VSANs to the respective port-channels:Port-Channel 30 Allowed VSAN 10,20,30Port-Channel 31 Allowed VSAN 11,21,31Once the VSAN is stretched across the sites as per the prereq for ViPR v2.2, ViPR will then automatically create the required IVR zones as part of the provisioning workflow. Note: The vArray should be set for Automatic Zoning for all this to occur.Example MDS ConfigurationThese are example configuration steps to be completed on both sites MDS switches in order to enable Cisco Inter-VSAN Routing (IVR is the standard for cross-connect zoning with VPLEX Metro) and to enable automatic cross-connect zoning with ViPR: FABRIC ‘A’ Switchesfeature ivrivr nativr distributeivr commitsystem default zone distribute fullsystem default zone mode enhancedivr vsan-topology autozone mode enhanced vsan 10zone mode enhanced vsan 20zone mode enhanced vsan 30vsan databasevsan 10 name “VSAN10”vsan 20 name “VSAN20”vsan 30 name “vplex1_wan_repl_vsan30”
interface port-channel 30channel mode activeswitchport mode Eswitchport trunk allowed vsan 10switchport trunk allowed vsan add 20switchport trunk allowed vsan add 30switchport description CROSS-SITE-LINKswitchport speed 8000switchport rate-mode dedicatedConfiguring FABRIC A switches Fcdoamin priorities:Site1:fcdomain priority 2 vsan 10fcdomain domain 10 static vsan 10fcdomain priority 100 vsan 20fcdomain domain 22 static vsan 20fcdomain priority 2 vsan 30fcdomain domain 30 static vsan 30Site2:fcdomain priority 100 vsan 10fcdomain domain 12 static vsan 10fcdomain priority 2 vsan 20fcdomain domain 20 static vsan 20fcdomain priority 100 vsan 30fcdomain domain 32 static vsan 30Example: configuring Inter-VSAN routing (IVR) Zones connecting an ESXi host HBA0 over VSANs 10 and 20 from site1->site2 and vice versa site2->site1 utilising the transit VSAN30:device-alias databasedevice-alias name VPLEXSITE1-E1_A0_FC02 pwwn 50:00:14:42:A0:xx:xx:02device-alias name VPLEXSITE1-E1_B0_FC02 pwwn 50:00:14:42:B0:xx:xx:02device-alias name VPLEXSITE2-E1_A0_FC02 pwwn 50:00:14:42:A0:xx:xx:02device-alias name VPLEXSITE2-E1_B0_FC02 pwwn 50:00:14:42:B0:xx:xx:02device-alias name ESXi1SITE1-VHBA0 pwwn xx:xx:xx:xx:xx:xx:xx:xxdevice-alias name ESXi1SITE2-VHBA0 pwwn xx:xx:xx:xx:xx:xx:xx:xxdevice-alias commitdevice-alias distributeivr zone name ESXi1SITE1-VHBA0_VPLEXSITE2-E1_A0_FC02member device-alias ESXi1SITE1-VHBA0 vsan 10member device-alias VPLEXSITE2-E1_A0_FC02 vsan 20ivr zone name ESXi1SITE1-VHBA0_VPLEXSITE2-E1_B0_FC02member device-alias ESXi1SITE1-VHBA0 vsan 10member device-alias VPLEXSITE2-E1_B0_FC02 vsan 20ivr zone name ESXi1SITE2-VHBA0_VPLEXSITE1-E1_A0_FC02member device-alias ESXi1SITE2-VHBA0 vsan 20member device-alias VPLEXSITE1-E1_A0_FC02 vsan 10
fcdomain priority 2 vsan 21fcdomain domain 21 static vsan 21fcdomain priority 100 vsan 31fcdomain domain 33 static vsan 31Example configuring Inter-VSAN routing (IVR) zones connecting an ESXi host HBA1 over VSANs 11 and 21 from site1->site2 and vice versa site2->site1 utilising the transit VSAN31:device-alias databasedevice-alias name VPLEXSITE1-E1_A0_FC02 pwwn 50:00:14:42:A0:xx:xx:03device-alias name VPLEXSITE1-E1_B0_FC02 pwwn 50:00:14:42:B0:xx:xx:03device-alias name VPLEXSITE2-E1_A0_FC02 pwwn 50:00:14:42:A0:xx:xx:03device-alias name VPLEXSITE2-E1_B0_FC02 pwwn 50:00:14:42:B0:xx:xx:03device-alias name ESXi1SITE1-VHBA1 pwwn xx:xx:xx:xx:xx:xx:xx:xxdevice-alias name ESXi1SITE2-VHBA1 pwwn xx:xx:xx:xx:xx:xx:xx:xxdevice-alias commitdevice-alias distributeivr zone name ESXi1SITE1-VHBA1_VPLEXSITE2-E1_A0_FC03member device-alias ESXi1SITE1-VHBA1 vsan 11member device-alias VPLEXSITE2-E1_A0_FC03 vsan 21ivr zone name ESXi1SITE1-VHBA1_VPLEXSITE2-E1_B0_FC03member device-alias ESXi1SITE1-VHBA1 vsan 11member device-alias VPLEXSITE2-E1_B0_FC02 vsan 21ivr zone name ESXi1SITE2-VHBA1_VPLEXSITE1-E1_A0_FC03member device-alias ESXi1SITE2-VHBA0 vsan 20member device-alias VPLEXSITE1-E1_A0_FC02 vsan 10ivr zone name ESXi1SITE2-VHBA1_VPLEXSITE1-E1_B0_FC03member device-alias ESXi1SITE2-VHBA1 vsan 21member device-alias VPLEXSITE1-E1_B0_FC03 vsan 11ivr zoneset name IVR_vplex_hosts_XC_Bmember ESXi1SITE1-VHBA1_VPLEXSITE2-E1_A0_FC03member ESXi1SITE1-VHBA1_VPLEXSITE2-E1_B0_FC03member ESXi1SITE2-VHBA1_VPLEXSITE1-E1_A0_FC03member ESXi1SITE2-VHBA1_VPLEXSITE1-E1_B0_FC03ivr zoneset activate name IVR_vplex_hosts_XC_Bivr commitVerification commands to check status of configuration:show fcdomain domain-listVerifies unique domain ID assignment. If a domain overlap exists, edit and verify the allowed-domains list or manually configure static, non-overlapping domains for each participating switch and VSAN.show interface briefVerifies if the ports are operational, VSAN membership, and other configuration settings covered previously.show fcns databaseVerifies the name server registration for all devices participating in the IVR.
show zoneset activeDisplays zones in the active zone set. This should include configured IVR zones.show ivr fcdomainDisplays the IVR persistent fcdomain database.show ivr internalShows the IVR internal troubleshooting information.show ivr pending-diffShows the IVR pending configuration.show ivr service-groupShows the difference between the IVR pending and configured databases.show ivr tech-supportshows information that is used by your customer support representative to troubleshoot IVR issues.show ivr virtual-domainsShows IVR virtual domains for all local VSANs.show ivr virtual-fcdomain-add-statusShows IVR virtual fcdomain status.show ivr vsan-topologyVerifies the configured IVR topology.show ivr zonesetVerifies the IVR zone set configuration.show ivr zoneVerifies the IVR zone configuration.clear ivr zone databaseClears all configured IVR zone information.Note: Clearing a zone set erases only the configured zone database, not the active zone database.Useful CISCO Docs:Cisco IVR TroubleshootingIVR Zones and ZonesetsInter-VSAN Routing (IVR) definition: An IVR zone is a set of end devices that are allowed to communicate across VSANs within their interconnected SAN fabric. An IVR path is a set of switches and Inter-Switch Links (ISLs) through which a frame from an end device in one VSAN can reach another end device in some other VSAN. Multiple paths can exist between two such end devices. A Transit VSAN is a VSAN that exists along an IVR path from the source edge VSAN of that path to the destination edge VSAN of that path, in the example solution diagram below you will see that VSAN 30 and VSAN 31 are transit VSANs. Distributing the IVR Configuration Using CFS: The IVR feature uses the Cisco Fabric Services (CFS) infrastructure to enable efficient configuration management and to provide a single point of configuration for the entire fabric in the VSAN. Thanks to @HeagaSteve,Joni,Hans,@dclauvel & Sarav for providing valuable input.Leave a comment
CISCO MDS – Useful ‘Show’ Commands
September 30, 2015 Cisco CISCO MDS, COMMANDS, show, Useful CONFIG:show startup-configshow running-configshow running-config diffshow run |include host|gateway|ntp|fcdomain|http|telnet|zoneset|vsanshow start |include host|gateway|ntp|fcdomain|http|telnet|zoneset|vsanshow install all statusshow switchnameshow wwn switchshow switch summaryshow versionshow cdp neighborsshow bootshow system internal flashshow snmp hostshow ntp peersshow ssh servershow telnet serverSwitch Serial Number:The switch serial number can be retrieved by using either of the two following commands:show license host-idshow sprom backplane 1 | grep “Serial”LICENSING:show featureshow license briefshow license usageshow port-licenseshow port-license | grep -i acquireHARDWARE:show hardwareshow hardware internal errors allshow environmentshow environment temperatureshow environment temperature module 1show environment powershow inventoryshow inventory moduleshow inventory chassisshow inventory xbarshow clockINTERFACES:show interface mgmt0show ip interfaceshow ip interface mgmt 0show interface brief
show interface fc1/1 briefshow run interface fc1/1show interface descriptionshow interface description | grep VMAXshow interface fc1/1 | include descriptionshow interface transceivershow interface transceiver detailsshow interface fc1/1 transceivershow interface fc1/1 transceiver detailsshow int | include CRCshow int | include errorsShow int fc1/1 | include errorsShow int fc1/1-48 | include errorsShow int fc1/1-32 | include errorsShow int fc2/1-32 | include errorsshow interface fc1/1-32,fc2/1-32 | include errorsshow interface fc1/1-32,fc2/1-32,fc3/1-32,fc4/1-32 | include errorsshow interface fc1/15,fc2/15,fc3/21,fc4/22 | include errorsshow int fc1/1,fc1/12 |include fc|vsan|description|CRC|errorsshow port-channel summaryshow port-channel usageshow port-channel databaseshow port-channel consistencyshow interface port-channel Xshow run interface port-channel Xshow port internal infoshow port internal info interface fc1/1show port internal info interface port-channel Xshow port-resources module 1show port-resources module 2VSANs (Virtual SANs):show vsanshow vsan membershipshow vsan membership usageshow vsan X membershipshow vsan membership interface fc1/1show vsan membership interface fc1/1-32show vsan membership interface port-channel Xshow topology vsan XFLOGI (FABRIC LOGIN):*Displays devices connected locally over physical ports.show flogi databaseshow flogi database detailsshow flogi database interface fc1/1show flogi database interface port-channel Xshow flogi database vsan X
show flogi database fcid 0x000xxxshow flogi internal info flogi-table vsan Xshow flogi internal event-history debugsshow flogi internal vsan Xshow flogi internal errorsshow flogi internal vsan-state XFCDOMAIN (Fibre Channel domain):*Displays global information about fcdomain configurations.show fcdomainshow fcdomain vsan Xshow fcdomain domain-listshow fcdomain domain-list vsan Xshow fcdomain address-allocation vsan XFCNS (Fibre Channel Name Server):*Displays wwn&fcid including devices connected over IVR/PC/ISL.show fcns databaseshow fcns database detail vsan Xshow fcns database fcid 0x010440 detail vsan Xshow rscn statistics vsan Xshow fspf database vsan XFC & DEVICE ALIAS:show fcaliasshow fcalias vsan Xshow fcalias pending vsan Xshow device-alias databaseZONING:show zone (Displays all VSANs)show zone statusshow zone status vsan X (Display zoning mode status enhanced/basic)show zone activeshow zone active vsan Xshow zone vsan Xshow zone statisticsshow zone statistics vsan Xshow zone active vsan Xshow zone active vsan X | grep ZoneHostNameshow zone analysis vsan Xshow zone analysis active vsan Xshow zone policy vsan Xshow zone pending-diff vsan Xshow zone member pwwn 21:00:00:XX:XX:XX:XX:XXshow zone name ZoneXshow zonesetshow zoneset vsan X-Yshow zoneset active (An asterix (*) next to the device indicates it is logged into the name server)show zoneset vsan X-Y
show zoneset active vsan Xshow zoneset briefshow zoneset brief vsan Xshow zone-attribute-group vsan Xshow zoneset pending active vsan Xshow zoneset pending vsan XIVR (Inter VSAN Routing):show ivrshow ivr vsan-topologyshow ivr zoneshow ivr zone | grep HostZoneNameshow ivr zoneset statusshow ivr zoneset activeshow ivr internal fcns databaseCFS (Cisco Fabric Services):show cfs merge statusshow cfs peersshow cfs statusSUPPORT:show system uptimeshow tech-support briefshow tech-support detailShow tech-support flogiShow tech-support fcdomainshow tech-support vsan xshow tech-support zoneshow tech-support zone vsan Xshow tech-support ivrshow logging serverShow logging log fileshow logging last linesShow ntp peer-statusshow system healthshow accounting logshow processes cpushow processes cpu historyshow processes cpu module 1show processes cpu module 2show processes logshow processes log detailsshow processes memoryshow flashLeave a comment
Cisco Nexus 3064 – Configuring Jumbo Frames September 2, 2015 Cisco 3064, Cisco, jumbo, nexus, qos The default MTU size on a Nexus 3064 switch is 1500 bytes, the following details how to reconfigure the switch for a system wide MTU value of 9216(jumbo).——————————————————————————–Note: The Cisco Nexus 3000 Series switch does not fragment frames. As a result, the switch cannot have two ports in the same Layer 2 domain with different maximum transmission units (MTUs). A per-physical Ethernet interface MTU is not supported. Instead, the MTU is set according to the QoS classes. You modify the MTU by setting Class and Policy maps.As per Cisco Documentation——————————————————————————–Configuring Jumbo Frames:Begin by creating a policy-map of type network-qos named aptly in this example ‘JumboFrames’ and assign as the system-qos. (As stated above you cannot configure on a per interface level).
n3k-sw# config tn3k-sw(config)# policy-map type network-qos ?WORD Policy-map name (Max Size 40)n3k-sw(config)# policy-map type network-qos JumboFramesn3k-sw(config-pmap-nq)# class type network-qos class-defaultn3k-sw(config-pmap-nq-c)# mtu 9216n3k-sw(config-pmap-nq-c)# system qosn3k-sw(config-sys-qos)# service-policy type network-qos ?WORD Policy-map name (Max Size 40)n3k-sw(config-sys-qos)# service-policy type network-qos class-defaultn3k-sw(config-sys-qos)# show policy-map type network-qosType network-qos policy-maps===============================policy-map type network-qos JumboFramesclass type network-qos class-defaultmtu 9216
Verification of the change can be validated by running a ‘show queuing interface’ command on one of the 3k interfaces (interface Ethernet 1/2 in this example):
n3k-sw# show queuing interface ethernet 1/2
Ethernet1/2 queuing information:qos-group sched-type oper-bandwidth0 WRR 100qos-group 0HW MTU: 9216 (9216 configured)drop-type: drop, xon: 0, xoff: 0If you run the ‘show interface’ command then a value of 1500 will be displayed despite the system wide change that was made:n3k-sw# show queuing interface ethernet 1/2
CISCO UCS – Rebooting Fabric Interconnect(s) April 10, 2015 Cisco cisco ucs, Fabric Interconnect, Reboot, State Begin by connecting to the cluster IP over SSH and checking which FI is Primary/Subordinate:FI-A# show cluster stateA: UP, PRIMARYB: UP, SUBORDINATE
Note: show cluster extended-state will provide more detailed information.Having confirmed the ‘B’ fabric switch is the subordinate connect to FI-B mgmt cli interface:FI-A# connect local-mgmt B
From FI-B local-mgmt interface issue the reboot command:
FI-B(local-mgmt)# rebootBefore rebooting, please take a configuration backup.Do you still want to reboot? (yes/no):yes
Run the ‘cluster state’ command again to check on the status of FI-B:FI-A(local-mgmt)# show cluster stateA: UP, PRIMARYB: DOWN, INAPPLICABLEHA NOT READYPeer Fabric Interconnect is down
Once the cluster enters a HA READY status, make FI-B the Primary switch in order to reboot FI-A:FI-A(local-mgmt)# cluster lead b
Note: After initiating a fail over the SSH session will disconnect, re-connect to the cluster and confirm cluster state.Connect to local mgmt ‘a’ and reboot FI-A:FI-B# connect local-mgmt aFI-A(local-mgmt)# rebootBefore rebooting, please take a configuration backup.Do you still want to reboot? (yes/no):yes
Confirm HA READY status before setting FI-A back to PRIMARY:FI-B# show cluster stateB: UP, PRIMARYA: UP, SUBORDINATEHA READY
Set FI-A as PRIMARY, this will need to be set from current PRIMARY FI-B mgmt interface:
FI-B# connect local-mgmt bFI-B(local-mgmt)# cluster lead a
Leave a comment
Cisco Nexus 5K – Unified Port Conversion March 11, 2015 Cisco Cisco, conversion, nexus, PORT, unified Nexus 5000 series UP switches have the option of either enabling individual ports as Ethernet or Fibre Channel ports. One of the strict guidelines is to begin enabling ethernet ports at the first port 1/1 and in the case of Fiber Channel begin at the last port of the module and work backwards. If this rule is not followed you will receive the following error(s):ERROR: Ethernet range starts from first port of the moduleERROR: FC range should end on last port of the module
For this example we will configure Slot-4 on a 5596-UP switch; enabling all 16 ports on the modules for fibre channel connectivity. Here is the view of the switch prior to converting the ports to FC:
As you can see the first Slot has 48 unified ports and we have added an additional unified module to Slot-4. Following the unified port guidelines we would start assigning FC ports at 1/48 for Slot-1 and 4/16 for Slot-4 (As per this example). With a 5596-UP switch the first Slot has 32 unified ports built in, with the option of adding an additional module to Slot-2, again following the guidelines for a 5548-UP switch the Ethernet ports begin at 1/1, FC at 1/32 and for Slot-2 Ethernet allocation begins at 2/1 and FC at 2/16. Converting the entire Slot-4 module to FC:switch# Show interface brief
Eth4/1 1 eth access down SFP validation failed 10G(D) —Eth4/2 1 eth access down SFP validation failed 10G(D) —Eth4/3 1 eth access down SFP not inserted 10G(D) —Eth4/4 1 eth access down SFP not inserted 10G(D) —Eth4/5 1 eth access down SFP not inserted 10G(D) —Eth4/6 1 eth access down SFP not inserted 10G(D) —Eth4/7 1 eth access down SFP not inserted 10G(D) —Eth4/8 1 eth access down SFP not inserted 10G(D) —Eth4/9 1 eth access down SFP not inserted 10G(D) —Eth4/10 1 eth access down SFP not inserted 10G(D) —Eth4/11 1 eth access down SFP not inserted 10G(D) —Eth4/12 1 eth access down SFP not inserted 10G(D) —Eth4/13 1 eth access down SFP not inserted 10G(D) —Eth4/14 1 eth access down SFP not inserted 10G(D) —Eth4/15 1 eth access down SFP validation failed 10G(D) —Eth4/16 1 eth access down SFP validation failed 10G(D) —Enter global config mode:switch# configure terminal
Configure all 16 Ports on the unified module as a native Fibre Channel port:switch(config-slot)# port 1-16 type fc
Save config:switch(config-slot)# copy running-config startup-config
Important point to note here is that a full reload is not required when converting a port on an expansion module(GEM), you just need to simply power cycle the GEM card (In the case of converting a port on the main slot-1 then a full reload of the switch is required.):switch(config-slot)# poweroff module 4switch(config-slot)# no poweroff module 4
View the port configuration after power cycle of Slot-4:switch# show interface brief
fc4/1 1 auto on up swl F 8 —fc4/2 1 auto on up swl F 8 —fc4/3 1 auto on sfpAbsent — — —fc4/4 1 auto on sfpAbsent — — —fc4/5 1 auto on sfpAbsent — — —fc4/6 1 auto on sfpAbsent — — —fc4/7 1 auto on sfpAbsent — — —fc4/8 1 auto on sfpAbsent — — —fc4/9 1 auto on sfpAbsent — — —fc4/10 1 auto on sfpAbsent — — —fc4/11 1 auto on sfpAbsent — — —fc4/12 1 auto on sfpAbsent — — —fc4/13 1 auto on sfpAbsent — — —fc4/14 1 auto on sfpAbsent — — —fc4/15 1 auto on down swl — —fc4/16 1 auto on down swl — —
Note: after issuing a conversion to FC on the switch you have 120 days to acquire a permanent license:switch# show license usage
Feature Ins Lic Status Expiry Date CommentsCount——————————————————————————–FCOE_NPV_PKG No – Unused –FM_SERVER_PKG No – Unused –ENTERPRISE_PKG No – In use Grace 119D 20HFC_FEATURES_PKG No – In use Grace 119D 20H
VMFEX_FEATURE_PKG No – Unused –ENHANCED_LAYER2_PKG No – Unused –LAN_BASE_SERVICES_PKG No – Unused –LAN_ENTERPRISE_SERVICES_PKG No – Unused –——————————————————————————–3 Comments
Cisco MDS – Upgrading Firmware October 3, 2014 Cisco 9000, Cisco, code, Firmware, MDS, Upgrade MDS 9000 Series Firmware UpgradeIt is always good practice to read the software ‘release notes’ before proceeding with an upgrade. The ‘Cisco MDS 9000 NX-OS and SAN-OS Software’ release notes can be found here.These are the steps I follow when upgrading:1. Open an SSH session to the switch.2. Take a backup of your configuration. Firstly ensure that your running configuration has been applied to the startup-config:copy running-config startup-configThen backup your startup configuration. In this example we are backing up to an ftp server:copy system:startup-config ftp://FTPserver_IP/startup-config.cfg3. Ensure the switch is in a healthy state before proceeding:
If the MDS is a Director Level switch, then check the redundancy and module status:show system redundancy statusshow module
During the upgrade the standby supervisor is upgraded first. Once the upgrade has completed on the standby then an automatic switchover occurs and the upgraded standby becomes primary while the other supervisor is upgraded. The odd time I have experienced with a Director switch that the supervisor does not switch back to the original primary after the code upgrade has completed. In this scenario simply use these cmds to switch manually:attach module #system switchover (if running on standby)
5. Change directory to bootflash and upload the new bin files to the switch. This example uses an ftp transfer:copy ftp://user@IP_Address/m9100-s3ek9-kickstart-mz.5.2.8c.bin m9100-s3ek9-kickstart-mz.5.2.8c.bincopy ftp://user@IP_Address/m9100-s3ek9-mz.5.2.8c.bin m9100-s3ek9-mz.5.2.8c.bin6. Ensure the code was uploaded to the bootflash directory successfully:
7. Determine if the upgrade will be non-disruptive:show install all impact system bootflash:///m9100-s3ek9-mz.5.2.8c.binFor a non-disruptive upgrade the switches are designed in such a way that the ports will remain connected and traffic flow will continue non-disrupted throughout the upgrade. This is so because the switch has been engineered in such a way that the control plane is separate to the data plane. In the case of a director level switch the modules are upgraded and rebooted in a rolling fashion one at a time non-disruptively(non-disruptively due to the separation of the control and data planes). 8. Check the MD5 and confirm the files validity:show version image bootflash:///m9100-s3ek9-mz.5.2.8c.binshow version image bootflash:///m9100-s3ek9-kickstart-mz.5.2.8c.bin9. Check for any incompatibilities between the running and the upgrade code versions. This will check for features that are currently running on the switch but are not supported on the upgrade code level:show incompatibility system bootflash:///m9500-sf2ek9-mz.5.2.8c.bin10. Enter the following command to install the new firmware on the switch:install all system m9100-s3ek9-mz.5.2.8c.bin kickstart m9100-s3ek9-kickstart-mz.5.2.8c.bin
11. Display the status of the upgrade:‘show install all status’
12. Run ‘show version’ to ensure the switch is now running at the upgraded code level. As you can see from the below example the ‘system version’ is still on the previous firmware level – a reload is required to apply the upgrade. NOTE: A reload is disruptive to traffic flow (As pointed out by @dynamoxxx below). This is not common and I have only identified this with the 9148 Switch when upgrading from 5.0.x to 5.8.x.
After reload the system version should be at the upgraded version:
It is good practice to delete the old install files from the bootflash directory:cd bootflash:delete m9100-s3ek9-kickstart-mz.5.0.1a.bin
Cisco MDS – Clear All Zoning Configuration August 13, 2014 Cisco CISCO MDS, clear, DELETE, remove, zoneset, Zoning The steps below detail the process of clearing all zoning configurations on an MDS switch. Including: fcaliases, zonesets and zones. If you wish to remove individual zones from a zoneset then please see post here: How To Remove Zones from an Active ZonesetNote: Ensure this is a standalone switch; if it is connected to other switches in the fabric then you may potentially affect the entire fabric.1. Firstly determine the names of the active zonesets for each vsan. In this example we will clear down all the zoning associated with the zonset “vsan10_zs” on vsan 10:MDS-9148# show zoneset active | inc zonesetzoneset name vsan10_zs vsan 102. Next you will need to deactivate the zoneset “vsan10_zs” on vsan 10:MDS-9148# conf tMDS-9148(config)# no zoneset activate name vsan10_zs vsan 10Enhanced zone session has been created. Please ‘commit’ the changes when done.MDS-9148(config)# zone commit vsan 10Commit operation initiated. Check zone status3. Remove the zonset “vsan10_zs” from the configuration:MDS-9148(config)# no zoneset name vsan10_zs vsan 10MDS-9148(config)# zone commit vsan 10MDS-9148(config)# show zoneset activeZoneset not present4. Clear all the zones from the database associated with vsan 10:MDS-9148# clear zone database vsan 10Enhanced zone session has been created. Please ‘commit’ the changes when done.MDS-9148(config)# zone commit vsan 10MDS-9148(config)# show zoneZone not presentMDS-9148# show fcaliasAlias not present5. Clear any device alias entries:MDS-9148(config)# clear device-alias database
MDS-9148(config)# device-alias commitMDS-9148(config)# show device-alias database6. Exit config mode, save your running config to startup and reload the switch:MDS-9148(config)# exitMDS-9148# copy run startup-config[########################################] 100%Copy complete, now saving to disk (please wait)…MDS-9148# reloadThis command will reboot the system. (y/n)? [n] yThen apply your new zoning configuration:copy ftp://FTP-Server-IP/Zoning.cfg system:running-configEXAMPLE#### FABRIC A ####show zoneset active | inc zonesetconf tno zoneset activate name vsan10_zs vsan 10zone commit vsan 10no zoneset name vsan10_zs vsan 10zone commit vsan 10show zoneset activeclear zone database vsan 10zone commit vsan 10show zoneshow fcaliasclear device-alias databasedevice-alias commitshow device-alias databaseexitcopy run startup-config#### FABRIC B ####show zoneset active | inc zonesetconf tno zoneset activate name vsan11_zs vsan 11zone commit vsan 11no zoneset name vsan10_zs vsan 11zone commit vsan 11show zoneset activeclear zone database vsan 11zone commit vsan 11show zoneshow fcaliasclear device-alias databasedevice-alias commitshow device-alias database
exitcopy run startup-config## Then apply your new zoning configuration: ##copy ftp://10.10.10.1/ZoningA.cfg system:running-configshow zoneset activecopy run startcopy ftp://10.10.10.1/ZoningB.cfg system:running-configshow zoneset activecopy run startIf prompted for ‘vrf’ the default entry is ‘management’:Enter vrf (If no input, current vrf ‘default’ is considered): management1 Comment
CISCO UCS Blades – Memory Troubleshooting July 11, 2014 Cisco Blade, Cisco, Error, MEMORY, TROUBLESHOOTING This is a guest blog post kindly contributed by Eric Daly @daly_eric.In an effort to pin point specific DIMMs within UCS that are throwing an error, please follow these simple steps. Be aware that an entire memory channel with up to 3 DIMMs may show as disabled in a channel, all because of one DIMM with uncorrectable errors.1) Check the Inventory > Memory tab to see which DIMMs are not registering. Make note of the DIMM Location (F0,F1,F2) as per Below:
2) Review the SEL Log and search for the specific DIMM throwing “uncorrectable” “memory error”. In this case you will see from the image below that the F2 DIMM was causing the issue. If nothing shows in SEL log perform steps 3-5.
3) Reset CIMC controller of blade (Recover Server > Reset CIMC (Server controller). Wait a minute or 2.4) Re-acknowledge blade. Takes 2-3 mins5) Review SEL Log again as per step 2 in order to identify the faulting DIMM.DEEPER ANALYSIS1) Download techsupport for the specific chassis where the suspect blade is located.
2) Extract the tar and then extract the relvant zip file for suspect blade. There are 2 files which will give you a clear picture of memory DIMM failures. MrcOut.txt and DimmBl.log3) Locate the DimmBl.log file and open this with Word (not notepad).
Cisco UCS – Reinitialize FC Port Channel June 24, 2014 Cisco cisco ucs, Disable, Enable, Fabric Interconnect, FC Port Channel, Reinitialize Fabric Interconnect CLI:By connecting directly to the fabric interconnect you can quickly issue the following commands to Reinitialize (Disable&Enable) the specified FC Port Channel. Often this is required when initally configuring an FC Port Channel with an MDS. The example below will show how to Reinitialize Port Channel 10 on ‘Fabric A’ and Port Channel 11 on ‘Fabric B’:Note: for assistance on cmds – tail command with a ‘?’ Fabric ACommands issued in sequence:• scope fc-uplink• scope fabric A• scope port-channel 10• show• disable• commit-buffer• enable• commit-buffer• show• show detail expandFI-A# scope fc-uplinkFI-A /fc-uplink # scope fabric AFI-A /fc-uplink/fabric # scope port-channel 10FI-A /fc-uplink/fabric/port-channel # showPort Channel:Port Channel Id Name Oper State Oper Speed (Gbps)--------------- ---------- ---------------- -----------------10 FC-PC10-Fabric-AUp 32FI-A /fc-uplink/fabric/port-channel # disableFI-A /fc-uplink/fabric/port-channel* # commit-bufferFI-A /fc-uplink/fabric/port-channel # enableFI-A /fc-uplink/fabric/port-channel* # commit-bufferFI-A /fc-uplink/fabric/port-channel # show
Fabric B• scope fc-uplink• scope fabric B• scope port-channel 11• show• disable• commit-buffer• enable• commit-buffer• show• show detail expandIn order to troubleshoot the FC Uplink ports:• scope fc-uplink• scope fabric A – A|B
• show interface – this will display all FC Uplink Ports• show interface detail• scope interface 1 29• show interface detail• show faultConnect Via Nexus OS:connect nxos a | bshow san-port-channel databaseshow san-port-channel summaryshow san-port-channel internal info allshow interfaceshow interface briefshow interface fc1/29show interface transceiverCheck for FLOGI:show npv flogi-tableUCS Manager:Click on the SAN tab in UCS Manager, click to expand ‘SAN Cloud’ – ‘Fabric A’ – ‘FC Port Channels’. From here you have the option to Disable|Enable the highlighted FC Port Channel:
1 Comment
Cisco UCS – How to Query UCS for WWN’s Associated with Blades April 3, 2014 Cisco cisco ucs, powertool, wwn These are very useful trick’s in order to obtain a list of WWN’s associated with the blades in a UCS environment. Instead of trawling through the GUI you can easily connect to UCS via the
Cisco UCS PowerTool or SSH to the Fabric Interconnect and quickly retrieve the WWN information for each/All Host/blade’s in UCS.UCS PowerToolYou can download the latest version of Cisco UCS PowerTool from:UCS PowerTool DownloadFirstly launch the UCS PowerTool and Connect to the UCS system by issuing the cmd:PS C:\> Connect-Ucs Enter your fabric interconnect IP address hitting the return key and then inputting your creds.Once you have connected enter the following cmd to bring up a list of all the blades (service profiles) and their associated vHBA WWN’s:PS C:\> Get-UcsServiceProfile -type instance | Get-UcsVhba | Select Dn,Addr,NodeAddr
If you want to reduce the list to only WWPN‘s, then use the following:PS C:\> Get-UcsServiceProfile -type instance | Get-UcsVhba | Select Dn,Addr
Filter by “vHBA-0”:Get-UcsServiceProfile -type instance |Get-UcsVhba | select DN,Name,Addr| where {$_.Name -eq “vHBA-0”} | sort DNFilter by “vHBA-1”:Get-UcsServiceProfile -type instance |Get-UcsVhba | select DN,Name,Addr| where {$_.Name -eq “vHBA-1”} | sort DN
In order to display the associated VSAN details:PS C:\> Get-UcsServiceProfile -type instance | Get-UcsVhba | Get-UcsVhbaInterface | select Dn,Initiator,Vnet
Get all service profile instances in UCS:PS C:\> Get-UcsServiceProfile –Type instanceList Boot Policy assigned to each blade:C:\> Get-UcsServiceProfile -type instance | select Name,BootPolicyNameFabric Interconnect CLIAnother option is to connect directly to the fabric interconnect. Using the cmd “fi01-A# show server adapter identity” will return a detailed list all of the UCS blades WWN details:
For a brief list of all WWN’s assigned to each host use this simple cmd:sh identity wwn• To list an individual server WWPN details:fiA-31-A# scope chassis 1fiA-31-A /chassis # scope server 1fiA-31-A /chassis/server # scope adapter 1fiA-31-A /chassis/server/adapter # show host-fc-ifFC Interface:Id Wwn Model Name Operability———- ———————– ———- ———- ———–1 20:00:00:25:B5:25:A0:6F UCSB-MLOM-40G-01vHBA-0 Operable2 20:00:00:25:B5:25:B1:6F UCSB-MLOM-40G-01vHBA-1 Operable• From the scope server is is also possible to learn the DN(Distinguished Name):fiA-31-A /chassis/server # show server adapter vnicsFC Interface:Adapter Interface Vnic Dn Dynamic WWPN Type——- ——— ———- ———— —-
1 1 org-root/ls-xap-esx001/fc-vHBA-0 20:00:00:25:B5:25:A0:6F Fc1 2 org-root/ls-xap-esx001/fc-vHBA-1 20:00:00:25:B5:25:B1:6F Fc• Check which vHBA is assigned to fabric A/B:fiA-31-A# scope service-profile server 1/1fiA-31-A /org/service-profile # show vhbavHBA:Name Fabric ID Dynamic WWPN———- ——— ————vHBA-0 A 20:00:00:25:B5:25:A0:6FvHBA-1 B 20:00:00:25:B5:25:B1:6F• Get a full List of all WWPN’s based on Fabric A/B:fiA-31-A# scope orgfiA-31-A /org # show wwn-poolWWN Pool:Name Purpose Size Assigned——————– —————————- ———- ——–Global-WWNN-Pool Node WWN Assignment 128 9vHBA-0-Fabric-A Port WWN Assignment 128 9vHBA-1-Fabric-B Port WWN Assignment 128 9• List all Fabric-A WWPN and DN information:fiA-31-A# scope orgfiA-31-A /org # scope wwn-pool vHBA-0-Fabric-AfiA-31-A /org/wwn-pool # show initiatorWWN Initiator:Id Name Assigned Assigned To Dn———————– ———- ——– ————–20:00:00:25:B5:25:A0:6F Yes org-root/ls-xap-esx001/fc-vHBA-0• List all Fabric-B WWPN and DN information:fiA-31-A# scope orgfiA-31-A /org # scope wwn-pool vHBA-1-Fabric-BfiA-31-A /org/wwn-pool # show initiatorWWN Initiator:Id Name Assigned Assigned To Dn———————– ———- ——– ————–20:00:00:25:B5:25:B1:6F Yes org-root/ls-xap-esx001/fc-vHBA-1Thank you ‘Brendan Lucey’ for your assistance.3 Comments
Cisco MDS – How To Remove Zones from an Active Zoneset March 22, 2014 Cisco ACTIVE ZONESET, CISCO MDS, REMOVE ZONE 1. Firstly we need to know the specific names of the Zones that we intend to delete. To gather the full list of zone members within a Zoneset run show zoneset vsan xx. The output will return all of
the member names for the Zoneset, the output can be reduced if you know the naming conventions associated with the hosts; for example if the Zone names begin with V21212Oracle-1 then issuing the command show zoneset brief | include V21212Oracle-1 will return in this case all the Zones associated with Oracle-1:
2. To View the active Zones for Oracle-1 within the Zonseset: show zoneset active | include V21212Oracle-1
3. Example of Removing half the Zones (Paths) associated with host Oracle-1 from the active Zoneset name vsan10_zs:config tzoneset name vsan10_zs vsan 10no member V21212Oracle-1_hba1-VMAX40K_9e0no member V21212Oracle-1_hba1-VMAX40K_11e0no member V21212Oracle-1_hba2-VMAX40K_7e0no member V21212Oracle-1_hba2-VMAX40K_5e04. Re-activating the Zoneset vsan10_zs after the config changes of removing the specified Zoneset members:zoneset activate name vsan10_zs vsan 10zone commit vsan 105. Finally removing the Zones from the configuration:no zone name V21212Oracle-1_hba1-VMAX40K_9e0 vsan 10no zone name V21212Oracle-1_hba1-VMAX40K_11e0 vsan 10no zone name V21212Oracle-1_hba2-VMAX40K_7e0 vsan 10no zone name V21212Oracle-1_hba2-VMAX40K_5e0 vsan 10zone commit vsan 10endcopy run startConfirm configuration contains the correct Active Zoning:show zoneset brief | include V21212Oracle-1
CISCO MDS – Verifying VNX & VMAX Connectivity February 11, 2014 Cisco, VMAX, VNX CISCO MDS, EMC VNX, FCID, FCNS, PORT, VMAX Somtimes you may have encountered an issue where a VNX/VMAX front-end port gets cabled to the wrong MDS Switch Port that you had designed for and in fact the port description that was applied to the MDS Port is incorrect. In this case it is invaluable to have a command to verify the VNX/VMAX port connected to the MDS. There are many situations where this command would be useful; for example you may not have the ability to do a physical check as the DC is remote and you need to ensure the interface description that you are assigning the MDS FC Port is correct and resulting zoning configurations are accurate. Confirming these connections remotely through a command on the MDS is very benneficial during these types of situations. Else you may end up zoning to ports you did not design for.VMAX ExampleSo lets take an example: the design and expectation here is to have the VMAX Port 9G:1 connected to MDS FC Interface 2/37 and the interface was given the relevant description:
From this result we can see that the port was labeled as per design as VMAX 9G:1. Now we need to confirm this is the actual port connected to FC2/37.To analyse the connectivity of a specific interface we first need to retrieve the FCID for this port:show interface fc2/37
Now that we know the FCID is 0x010440, we can run our magic Cisco cmd to verify which VMAX FA Port is actually connected to the MDS Port FC2/37 :show fcns database fcid 0x010440 detail vsan 10Note: FCNS = Fibre Channel Name Server.
From the output we can confirm that there is a problem; the expected VMAX Port was 9G1 but in fact 7G1 is the VMAX port patched to FC2/37 (SYMMETRIX::000195701570::SAF- 7gB::FC::5876_229). Thus either we update the description of the interface or have the correct VMAX Port patched.To modify the description:interface fc2/37Switchport description VMAX20K-7g1no shutdownVNX Example
Interface FC1/25 as per design is connected to Service Processor ‘A2’ front-end port 2:
Running show interface fc1/25 in order to confirm port description and retrieve the FCID:
Now that we know the FCID is 0x010500, we can query the FCNS database for details of what is connected at the other end of FC1/25:show fcns database fcid 0x010500 detail vsan 10
From the output we can confirm the correct port is connected from the VNX.Another method of confirming the correct port is connected, is by gathering the WWPN from the VNX/VMAX port and then running the show flogi database interface fc 1/25 command on the MDS:
Reverse LookupFrom the VNX we can run a “naviseccli -h SP_IP port -list”:
From the output we can see that SPA_6(Logical Port) is connected to the MDS interface WWN 20:19:54:7f:ee:e2:9e:f8.Given this information we can lookup the Interface Port number by issuing: show fcs database | include 20:19:54:7f:ee:e2:9e:f8
Thus we can conclude from this output that the VNX Physcial Port SPA:2_2 is connected to MDS Port FC1/25.Note: If we want to look up the details of all the switch ports on the MDS this is the command:show fcns database detail1 Comment
EMC VMAX – 10K Zoning with Cisco MDS Switches October 6, 2013 Cisco, Vblock, VMAX 10K, Cisco, EMC, fabric, MDS, Symmetrix, VMAX, zoneset, Zoning In this example I will show how to complete the zoning for a two Host ESX Cluster (ESX01 & ESX02), using a dual Fabric connecting to a EMC VMAX 10K Dual Engine SAN. As can be seen from the image below this configuration will provide redundancy for the ESX host on both HBA’s as well as on the Switch and VMAX levels.
This example will detail Zoning the ESX Cluster Hosts to front-end ports on a VMAX10K (2xEngines/4xDirectors) using FA ports 1E0,2E0,3E0,4E0. The Best Practice for the VMAX10K, if beginning with 2 or more engines, is to assign a cluster across 2 VMAX Engines, one port per director for a total of 4 ports.Each VMAX Engine will have connectivity to each SAN Fabric.◆ Odd directors are connected to Fabric A (1E0,3E0).◆ Even directors are connected to Fabric B (2E0,4E0).In this configuration, the zones are created with one HBA and one FA port (2 Zones per HBA):◆ ESX HBA-0 is zoned to one port on each Engine. Using Director 1 Engine 1 and Director 3 of Engine 2. (Fabric A)◆ ESX HBA-1 is zoned to one port on each Engine. Using Director 2 Engine 1 and Director 4 of Engine 2. (Fabric B)A good rule of thumb is to use all the “zero” ports on directors first before utilizing the “one” ports –Go wide before you go deep.MDS-SERIES Zoning CommandsThe configuration steps below will detail creating:◆Alias’s for ESX Host’s
◆Alias’s for VMAX-10K Target’s◆Creating Zones◆Creating ZonesetsFABRIC ‘A’ SCRIPT##### Alias’s for ESX Host’s (Initiator’s)#####fcalias name esx-01_hba0 vsan 10member pwwn 20:00:00:25:B5:01:A0:01fcalias name esx-02_hba0 vsan 10member pwwn 20:00:00:25:B5:01:A0:02##### Alias’s for VMAX-10K (Target’s)#####fcalias name VMAX10K_1e0 vsan 10member pwwn 50:00:09:75:F0:xx:xx:00fcalias name VMAX10K_3e0 vsan 10member pwwn 50:00:09:75:F0:xx:xx:08##### Create ZONES #####Single-initiator-single-target is the preferred zoning practice.Note: EMC always recommends using one initiator and one target in each zone. ESX-01 HBA-0:zone name esx-01_hba0-VMAX10K_1E0 vsan 10member fcalias esx-01_hba0member fcalias VMAX10K_1E0zone name esx-01_hba0-VMAX10K_3E0 vsan 10member fcalias esx-01_hba0member fcalias VMAX10K_3E0ESX-02 HBA-0:zone name esx-02_hba0-VMAX10K_1E0 vsan 10member fcalias esx-02_hba0member fcalias VMAX10K_1E0zone name esx-02_hba0-VMAX10K_3E0 vsan 10member fcalias esx-02_hba0member fcalias VMAX10K_3E0##### ZONESET #####zoneset name vsan10_zs vsan 10member esx-01_hba0-VMAX10K_1E0member esx-01_hba0-VMAX10K_3E0member esx-02_hba0-VMAX10K_1E0member esx-02_hba0-VMAX10K_3E0 zoneset activate name vsan10_zs vsan 10zone commit vsan 10end##### CONFIRM NEW ADDITIONS #####show zoneset briefshow zoneset name vsan10_zsshow zoneset active
show zone active vsan 10 | grep esx-01_hba0show zone active vsan 10 | grep esx-02_hba0show zone active vsan 10 | grep 20:00:00:25:B5:01:A0:01show zone active vsan 10 | grep 20:00:00:25:B5:01:A0:02FABRIC ‘B’ SCRIPT##### Alias’s for ESX Host’s (Initiator’s)#####fcalias name esx-01_hba1 vsan 11member pwwn 20:00:00:25:B5:01:B1:01fcalias name esx-02_hba1 vsan 11member pwwn 20:00:00:25:B5:01:B1:02##### Alias’s for VMAX-10K (Target’s)#####fcalias name VMAX10K_2E0 vsan 11member pwwn 50:00:09:75:F0:xx:xx:0Cfcalias name VMAX10K_4E0 vsan 11member pwwn 50:00:09:75:F0:xx:xx:04##### Create ZONES #####zone name esx-01_hba1-VMAX10K_2E0 vsan 11member fcalias esx-01_hba1member fcalias VMAX10K_2E0zone name esx-01_hba1-VMAX10K_4E0 vsan 11member fcalias esx-01_hba1member fcalias VMAX10K_4E0zone name esx-02_hba1-VMAX10K_2E0 vsan 11member fcalias esx-02_hba1member fcalias VMAX10K_2E0zone name esx-02_hba1-VMAX10K_4E0 vsan 11member fcalias esx-02_hba1member fcalias VMAX10K_4E0##### Create ZONESET #####zoneset name vsan11_zs vsan 11member esx-01_hba1-VMAX10K_2E0member esx-01_hba1-VMAX10K_4E0member esx-02_hba1-VMAX10K_2E0member esx-02_hba1-VMAX10K_4E0 zoneset activate name vsan11_zs vsan 11zone commit vsan 11end##### CONFIRM NEW ADDITIONS #####show zoneset briefshow zoneset name vsan11_zsshow zoneset activeshow zone active vsan 11 | grep esx-01_hba1show zone active vsan 11 | grep esx-02_hba1
show zone active vsan 11 | grep 20:00:00:25:B5:01:B1:01show zone active vsan 11 | grep 20:00:00:25:B5:01:B1:02By using VMware ESX Servers with multiple physical HBA’s and connecting to multiple directors in different engines this will benefit I/O intensive workloads and will increase redundancy. Balancing accross resources is always the best approach. This is an example configuration and it is always advisible to utilize the EMC tools available to help determine your exact required configuration.EXAMPLE SINGLE ENGINE DESIGN:This is the proposed design with the ports cabled as follows for the initial Cluster:Cluster 1 – FABRIC_A 2E0, 1G0FABRIC_B 1E0, 2G0Essentially splitting ports from each director across different fabrics as per the following diagram:
Then Incrementing Port usage per cluster for example:Cluster 2 – FABRIC_A 2F0, 1H0FABRIC_B 1F0, 2H0
From such a configuration if a switch failure occurs then we lose half the ports on each director but at least both directors can cater for the workload as opposed to one director. 8 Comments
Cisco MDS Zoning – RENAME June 28, 2013 Cisco Cisco, MDS, Rename, Zoning In this post, I’ll detail some useful commands that can be leveraged to rename Cisco zoning components:
FCALIASZONEZONESET
RENAME ALIAS FOR HOSTS (vsan id of 10):switch(config)# fcalias rename old-AliasName new-AliasName vsan 10RENAME ZONES:switch(config)# zone rename old-ZoneName new-ZoneName vsan 10RENAME ZONESETS:switch(config)# zoneset rename old-ZoneSetName new-ZoneSetName vsan 10Once complete Activate and Commit these changes:zoneset activate name vsan10_zs vsan 10zone commit vsan 10To view the changes made:switch# show fcaliasDisplays alias mappings.switch# show zoneDisplays zone mappings.switch# show zonesetDisplays all zone sets.switch# show zoneset activeDisplays the active zone set for each VSAN, includingwhich devices have logged in and are communicating.switch# show flogi databaseDisplays the devices that have logged into the fabric.Retrieve pWWNs for aliases and zoning from thisdatabase.Example of changing 4 Hosts on both Fabric A&B:Fabric Afcalias rename VMwareESX4_v0 VMwareESX5_v0 vsan 10fcalias rename VMwareESX3_v0 VMwareESX4_v0 vsan 10fcalias rename VMwareESX2_v0 VMwareESX3_v0 vsan 10fcalias rename VMwareESX1_v0 VMwareESX2_v0 vsan 10zone rename VMwareESX4_v0-VNX5400-b4 VMwareESX5_v0-VNX5400-b4 vsan 10zone rename VMwareESX4_v0-VNX5400-a4 VMwareESX5_v0-VNX5400-a4 vsan 10zone rename VMwareESX3_v0-VNX5400-b4 VMwareESX4_v0-VNX5400-b4 vsan 10zone rename VMwareESX3_v0-VNX5400-a4 VMwareESX4_v0-VNX5400-a4 vsan 10
