Hi Joseph, Let me answer your question in two parts, based on the scenarios that you provided. Of these scenarios, only the first one is currently possible. However, the second scenario will be possible as of the next major release - 2.1 - which is scheduled to be released later this year. 1) Direct Attach FCoE to Fabric Interconnect (supported) The Fabric Interconnects support direct attach FCoE arrays, which utilizes the FCoE Storage port type on the Fabric Interconnects.  In order to configure this type of connection, please refer to the following document: Configuring an FCoE Storage Port 2) Northbound FCoE from Fabric Interconnect to another Nexus switch (not yet supported) This scenario is still not supported as there is no FCoE available on the northbound uplink interfaces. The technical reason behind this is that the Fabric Interconnects don't support VE FCoE ports (yet), however the N5K/N7Ks have support for the VE ports. As a result, you would still be required to use Native Fibre Channel interfaces to connect to the N5K/N7K's which could then connect on to an FCoE storage array. The next major release of UCS software will support FCoE northbound out of the standard Ethernet uplinks. Hope that helps. Thanks, Michael ... View more

Hi John, To begin with, let me quickly give some background into the Cisco Flexible Flash Card. The Cisco Flexible Flash card is pre-installed with three software bundles, each on one of four preconfigured virtual drives (VDs). The fourth VD allows you to install an OS or embedded hypervisor. The VDs are configured as follows: Cisco UCS Server Configuration Utility (SCU). Hypervisor (HV). This is a VD that you can use for your own purposes. Cisco Drivers (Drivers). Cisco Host Upgrade Utility (HUU). The Hypervisor (HV) VD is a pre-configured 3GB partition on the Cisco FlexFlash SD and is called “HV Hypervisor_0”.  Due to the size of the partition, it is intended for ESXi installations only. What is important to understand is that each of these four VDs can be separately enabled or hidden from the host. The default is for all VDs to be hidden. In order to enable the VDs and make them visible to the host, you need to access the CIMC. If you haven't setup your CIMC on your C series server, please follow these instructions: Set up CIMC for UCS C-Series Server Once you have gained access to the CIMC, click on the following; Server Tab – click "Inventory" – Storage Tab – click “Cisco FlexFlash” - then "Configure Operational Profile": Where you will then be presented with the following screen: You want to ensure that you check the box for HV (hypervisor) so that it is enabled and thus will be visible to the host. After saving your changes, while still highlighting the FlexFlash, you can also select the tab "Virtual Drive Info" where you should see HV has "Host Accessible" set to "true". If not, ensure you saved the previous changes. Once this has been completed, don't forget to ensure that you have the hypervisor virtual drive higher, in the boot priority order, than the physical disks. This is to ensure that after you have installed your operating system, it will attempt to boot from the HV VD first, rather than the physical HDDs. If you have successfully enabled the HV VD, when you attempt to install an operating system (in my example, ESXi 5.0 - although in my example output I have all virtual drives enabled to illustrate what you would see from the installer), you should be able to see the HV VD partition: You can then select this HV Hypervisor_0 partition and proceed through the normal installation. Some additional information on Cisco's FlexFlash can be found via the following document: Overview of the Pre-Installed Cisco Flexible Flash Card Please let me know if this helps resolve your issue. If not, don't hesitate to ask follow up questions. Thanks, Michael ... View more

Hi Sarah, The error message "ENM source pinning failed" means that the UCS Fabric Interconnect (running in End Host Mode) is not able to pin the particular vNIC to an uplink interface. The most common reason this error occurs is when a VLAN assigned to a vNIC is not configured or available on one of the uplink interfaces. This prevents the UCS from pinning the vNIC traffic to an uplink, and therefore produces the error you describe. With disjoint L2 designs, you also want to ensure that: You have allowed the same range of VLANs on ALL uplinks that are a part of the same disjoint L2 domain. Do not overlap any VLANs across the disjoint L2 domains, as this isn't supported. Each VLAN can only connect to one upstream disjoint L2 domain. The only exception to this rule is default VLAN 1. Default VLAN 1 remains implicitly available on all uplink ports and port channels. You cannot explicitly assign default VLAN 1 to an uplink port or port channel, nor can you remove it from an uplink port or port channel. Do not configure a vNIC with VLANs from multiple L2 domains. If you define a vNIC to carry VLANs belonging to two separate disjoint L2 domains, pinning will fail, and a fault will be raised. This is because there is no single uplink interface that is able to carry ALL traffic defined on that particular vNIC. In short, each vNIC can only communicate with one disjoint L2 domain. Optionally, if the failing port is configured as an appliance port, the VLAN you are defining in the appliance section for this port, also needs to be defined in the regular ethernet VLANs section as well. If you don't, you will also get this error. You need to have the appliance VLAN also defined as a normal VLAN in UCSM. Please verify that you are following the above requirements. If you continue to have issues, please provide me with the output of: cae-syd-ca1-A(nxos)# show platform software enm internal event-history errors 1) Event:E_DEBUG, length:102, at 796222 usecs after Thu Aug  2 11:47:21 2012    [102] [enm_sif_state_change] [Veth819]: processing sif state 1 - no suitable interface found to pin SIF 2) Event:E_DEBUG, length:81, at 796212 usecs after Thu Aug  2 11:47:21 2012    [102] [enm_find_best_active_bif] [Veth819]: No suitable interface found to pin SIF This aids in troubleshooting, as it highlights the reason for the failure. In this example, you can see that Veth819 is failing as there isn't a suitable interface found to pin the server interface (SIF) to. Further details regarding Disjoint L2: Whitepaper - Deploy Layer 2 Disjoint Networks Upstream in End Host Mode Configuration Guide - Configuring Upstream Disjoint Layer-2 Networks Please let me know if this helps. Thanks, Michael ... View more

Hi Kerim, Thanks for the great question. An important part of troubleshooting is understanding what is and isn't normal. Obviously, to do that, you need to understand how the system works. In terms of the replica vEth port, this depends on if you have configured the vNIC within the service profile to utilize fabric failover. Assuming that you have enabled this feature on the vNIC interface, then to answer your question, yes, you're understanding is correct. There is a passive interface on the opposite Fabric Interconnect. If the Fabric Interconnect, through which the active interface is connected, fails (for whatever reason), the vNIC is failed over to the other Fabric Interconnect and that pre-provisioned passive interface then becomes active. This is true for both A to B, or B to A. Below is sample output where you can see the pre-provisioned interface on a test service profile I created. I only enabled Fabric Failover on vNIC1. You can see that this vNIC1 is provisioned on both Fabric A and Fabric B. However, vNIC1 on Fabric A (subsequently would be identified as vEth 808) has a state of Active/Primary. vNIC1 on Fabric B (subsequently would be identified as vEth 809) has a current status of Passive/Backup. I didn't configure this feature on vNIC2. As you can see, it is only provisioned on Fabric B and has a status of No Protection/Unprotected. A few things to note in relation to fabric failover: 1) Fabric Failover is only available for vNIC interfaces. It is NOT supported with vHBA interfaces. 2) It is ONLY supported on Cisco Virtual Interface Cards or the Cisco Menlo adapters (M71KR) Please let me know if this answers your question, or if you have any follow up questions. Thanks, Michael ... View more

Hi Khalid, What version of UCS firmware are you using? Also, what adapters have you got installed on the blades hosting the multicast devices? When it comes to Multicast on UCS, there are a couple of things to note: Currently, the UCS Fabric Interconnects have IGMP snooping enabled by default, and this cannot be disabled (this will be fixed in the next major release via CSCte64886). Therefore, you are required to have either of the following: Multicast router in the VLAN; or IGMP querier in the VLAN NOTE: Currently, the UCS Fabric Interconnects have no IGMP querier functionality (this will be fixed in the major release via CSCtg82066) and as such, you are required to enable this querier functionality on a device in the upstream L2 network Once you make the above changes, if you still have issues, please provide the following outputs: show ip igmp snooping mrouter (if you have Multicast router) show ip igmp snooping querier (if you have IGMP querier) show ip igmp snooping groups show ip igmp snooping vlan show ip igmp snooping statistics vlan Let me know how you go and if you have any further questions. Thanks, Michael ... View more

Hi Yang, The Cisco UCS does hardware abstraction/virtualization similar to how VMware does abstraction for the operating system from the underlying server, we do the same with the personalities that make up a server from the actual physical compute resources. Each time you create a service profile, you are creating a logical server which has all the characteristics of a physical server (MAC address, WWPNs, WWNNs, vNICs, vHBAs, BIOS, UUID, etc). You can then associate this service profile to any physical blade and that logical server with all your predefined personalities will utilize the physical compute resources. You can move this service profile around to any blade within the UCS cluster, each time it will maintain the characteristics that you defined, no matter which physical blade it is actually using. To answer your question, it is not possible to have 9 service profiles associated to a server pool of 8 blades and be running 9 ESXi instances. You can only run as many instances as there are physical blades. There is a one to one relationship between a service profile (once associated) and a physical blade. You can however have, for example, have 16 service profiles (logical servers) and only have 8 blades. You might have 8 service profiles associated during the day time, performing a particular task. Then at night, you need to run different workloads. So you could unassociate the original 8 service profiles, then associate the last 8 service profiles to run their workload on the physical compute resources during the night. Then switch back again in the morning. This is just an example. Seeing that you are new to the UCS, a good place to start is with our Video Library: http://www.cisco.com/en/US/prod/ps10265/ucs_advantage_video_library.html Hope that helps to clarify things for you. Thanks, Michael ... View more

A document with further explanation to this max-port scenario: https://communities.cisco.com/docs/DOC-26929 Thanks, Michael ... View more

Hi Diana, Yes that can be achieved assuming you are on 5.1(3)N1(1) or later. You configure this as part of Enhanced vPC. Have a look at the following documentation. www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/mkt_ops_guides/513_n1_1/n5k_enhanced_vpc.pdf Thanks, Michael ... View more