Cisco UCS 6120XP uplink considerations

HI,
I am working on a UCS design for a customer, I need to understand the physical connectivity of uplinks from 6120XP. Customer has 6509 in their environment with 48 x 1G eth modules. Unfortunately I cannot uplink 6120 using ethnet port to the LAN environment, Any suggestion or solution for followings:
- Can I connect/uplink 10G port from 6120XP to 1G port port on LAN switch probably 6509 or 2960.?
- Incase if Optical port is not available on 6509, can I use fabrci converter to convert the uplink from optical to eth, so that I could connect 6120XP with 6509?
Regards,
Kashif

Hi Kashif,
Yes you can connect the fabric Interconnect (FI) to 1G port of an uplink switch. The first 8 fixed ports can be configured to operate in 1 Gigabit Ethernet mode with the transceiver options specified for use with SFP-compatible ports using 1000BASE-T SFP GLC-T, you must specify the 1G rate of the port from the UCS manager.
I hope that I was in help to you!
Greetings,
Stanley

Similar Messages

Can the Cisco UCS 6120XP direct attach the EMC CX4-120 by fibre protocol ?

Hi all
I have two question for Cisco UCS
Q1: Can the Cisco UCS 6120XP direct attach the EMC CX4-120 by fibre protocol ?
Q2: I know the UCS 61XX Series support the Cisco SAN Switch(MDS).But we are only Brocade san switch ,
so UCS 61XX Series supoort Brocade san switch ?
Thanks , I really want to know the information .

Q1: The 6120s run in NPV (N_Port Virtualization) mode which means it acts as a proxy for the blade vHBAs and doesn't participate in flogi (fabric logins). When a fabric switch runs in this mode it requires an uplink to a faber switch for flogi and zoning. Due to this you cannot direct attach the the 6120 to an array's front-end fiber ports.
Q2: Yes you can uplink the 6120 to a Brocade fabric as long as the Brocade supports NPIV.

Cisco UCS network uplink on aggregation layer

Hello Cisco Community,
we are using our UCS (Version 2.21d) for ESX Hosts. Each host has 3 vnics as follows:
vnic 0 = VLAN 10 --> Fabric A, Failover Fabric B
vnic 1 = VLAN 20 --> Fabric B, Failover Fabric A
vnic 2 = VLAN 100 --> Fabric A, Failover Fabric B
Actually UCS is connected to the Access Layer (Catalyst 6509) and we are migrating to Nexus (vPC). As you know, Cisco UCS Fabric Interconnects can handle layer2 traffic itself. So we are planning to connect our UCS Fabric Interconnects directly to our new l3 nexus switch.
Does anyone have connect the UCS directly to l3? Do we have to pay attention to something? Are there some recommendations?
thanks in advance
best regards
/Danny

we are using ESXi 5.5 with dvswitche (distributed vswitch). In our cisco ucs powerworkshop, we discuss pros and contras of hard- and softwarefailover and we commit to use hardwarefailover. It is very fast and we have no problems actually.
This is a neverending and misunderstood story: your design should provide load balancing AND failover. Hardware failover only gives you the latter.In your design, you just use one fabric per Vlan, what a waste !
And think about the situation of a failover on a ESXi host with 200 VM's; one has to send out at least 200 GARP messages, and this is load on the FI CPU. Most likely dozens or more ESXi server are impacted......
Cisco best practise: if you use softswitch, let it do the loadbalancing and failover, don't use hardware failover.
see attachment (the paper is not up to date,
For ESX Server running vSwitch/DVS/Nexus 1000v and using Cisco UCS Manager Version 1.3 and below, it is recommended that fabric failover not be enabled, as that will require a chatty server for predictable failover. Instead, create regular vNICs and let the soft switch send
gARPs for VMs. vNICs should be assigned in pairs (Fabric A and B) so that both fabrics are utilized.
Cisco UCS version 1.4 has introduced the Fabric Sync feature, which enhances the fabric failover functionality for hypervisors as gARPs for VMs are sent out by the standby FI on failover. It does not necessarily reduce the number of vNICs as load sharing among the fabric is highly recommended. Also recommended is to keep the vNICs with fabric failover disabled, avoiding the use of the Fabric Sync feature in 1.4 for ESX based soft switches for quicker failover.

Lost 1 of 3 UCS chassin when upgrade firmeware on Cisco Interconter 6120XP

We have the following system \ environment, two redundantly connected Cisco 6120XP interconectorer linked to three Cisco UCS 5108x chassis with 13st cisco blade servers configured.
As information, I can say that we have NetApp FAS3240 storage and no Nexsus switches. We have vmware virtualization platform.
This is what happened.
We'd upgrade UCS Manager from version 1.4 directly to 2.03 (c).
At the time we had done a failover from the primary to the secondary interconector. We ran at that this time all network traffic through one I / O module on each chassis. When we pressed the upgrade on the primary interconecter so suddenly chassis number two reboot and we lose about 40 servers. VMWare has taken them down neatly but we lost it unfortunately. Now the question is why did this happen?
Rgds
Tobias

Hello Tobias,
Please confirm the sequence of events
1) You initially upgraded secondary FI and when you activated it, secondary FI along with IOMs attached to it came up successfully with upgraded version. Is this correct ?
2) Then you made upgraded ( secondary ) FI as primary by issuing " cluster lead " command from operating primary.
3) Initiated upgrade on old primary. Then activated new version.
Now servers lost connectivity.
Is my understanding correct ?
Few questions
1) Did all servers lose connectivity ( if you have multiple chassis ) ?
2) If not, do you know list of servers that lost the connectivity ?
3) Both LAN & SAN or only LAN or only SAN connectivity ?
4) Did you make any changes to resolve the issue ? If not, how did the connectivity got restored ?
I would suggest to you open a TAC SR with above information and UCSM and corresponding chassis tech support bundle.
Please include approx date / time of the event.
Padma

Cisco UCS with FEX system Component requirements

Hi ,
I am looking for quick suggestion for required components to have a VMware vSAN implemented using FEX system with maximum Fabric trough put. Ideally a configuration for without multipath using single Fabric switch and later on to be able to upgrade to Multipath fabric.
We are in great rush to provide POC concept and was looking if you folks can suggest me on this. If need be you want to talk to me more in detail I can available.
Appreciate your help here.
Who can I reach to able to pull up build and quote the configurations for implementing complete UCS solution.
Are these below components absolutely required ?
2 x Nexus 2232PP 10GE Fabric Extenders
The Cisco Nexus 2232PP 10GE provides 32 x 10Gb loss-less low latency Ethernet and Fiber Channel Over Ethernet (FCoE) Small Form-Factor Pluggable Plus (SFP+) server ports and eight 10 Gb Ethernet and FCoE SFP+ uplink ports in a compact 1 rack unit (1RU) form factor. They enable Seamless inclusion of UCS rack servers into UCS Manager domain with UCS blade servers when connected to the UCS 6200 Fabric Interconnects, providing converged LAN, SAN, and management connectivity.
We currently have these below servers :
2 x UCSC-BASE-M2-C460
        524 GB RAM
        No SSDs
        No VIC Card
        4 x SAS 1 TB Drives
        1 x L1 Intel 1 Gbps Ethernet Adapter
        1 x L2 10Gbps Ethernet Adapter
        1 x LSI Mega RAID SAS 9240-8i (no RAID 5 support, Need a card that supports RAID5)
1 x UCSC-C240-M3L
        132 GB RAM
        30 TB SAS HDD
        1 x VIC Card
        1 x Intel I350 Gigabit Ethernet Card with 4 ports
        1 x LSI Mega RAID SAS 9240-8i (no RAID 5 support, Need a card that supports RAID5)
1 x 5548UP Nexus Switch ( Will I be able to use this switch in place of Nexus 2232PP 10GE Fabric Extenders to achieve complete UCS solution)

Cisco UCS Manager 2.2 supports an option to connect the C-Series Rack-Mount Server directly to the Fabric Interconnects. You do not need the Fabric Extenders. This option enables Cisco UCS Manager to manage the C-Series Rack-Mount Servers using a single cable for both management traffic and data traffic.
If you need high performance low latency (storage, for VMware VSAN), direct connection to UCS Fabric Interconnect and/or N5k is recommended.

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

Cisco UCS Blade Deployment Without N5K or N7K ?

Dear all,
Is it possbile to deploy cisco UCS blade solution with only Blade Chassis, FI, FEX/IOM and using third party SAN and LAN switch ?
Thanks

Yes of course !
There are many installations with e.g. Brocade FC switches
The only caveat I see: are your uplink ethernet switches 1G or 10G; technically either one will work, however, with 1 G Northbound connectivity, some data flows are limited in bandwidth. see below

Cisco UCS VIF path unpinned

Hi,
I have the following scenario, Cisco UCS chassis with 2 Blade B440 placed in slot 5 and 7.
The blade in slot 5 is taking some time but the VIFs get pinned (FI Uplink) after approx 3 min.
as for the server in slot 7 the VIFs using the adapter 2 remains unpinned and even sometimes the "Link State" becomes "Unknown" and after a few seconds it changes to "up" but the "FI Uplink" always remaining unpinned.
Apparently the problem only occurs between the adapter 2 and FI-B
After checking the "IO module 2", I found that the Backplane Port 2/29 is in a failure status.
I changed the server slot from slot 7 to slot 1 and apparently everything was fine.
do you have any suggestions?

Hi,
you are right I have checked the statistics on the FI server port 1/4 and this is the only interface that has
fcs and Rx errors (about 30,000 in 2 days).
I changed the cable but the errors remained.
I even chnaged the IO module, still the same error.
I changed the FI interface to 1/7, I got the same errors on the new interface.
FInally I changed the policy of the IO module to "PortChannel" instead of "None" there is no errors neither on the port channel nor on the interface, this is really weird but after changing the behavior to portchannel, I was unable to reach my servers (neither the ESXI hosat, nor the VMs inside it)
I am really stucked, any suggestions?

UCS FI uplinks to a 7K... M132 required?

I'm in the process of purchasing a Nexus 7K and I will have UCS (w/ 6120 FIs) linking directly up to it. I may also have some IBM BCs that have uplinks via a 4K switch. I was under the impression that either of these switch interconnects required an uplink to an M132 card in the 7K. If this is not a requirement, I can cut my costs in half by purchasing the F132 line card. I will have other M series cards for routing purposes.
Thanks in advance...

You can uplink UCS fabric interconnects to either line card. The M card is required for FEX (Nexus 2000) support. At least 2 M1 cards are recommend for L3 and redundancy as the F1 cards are only L2. The new gen N7K F2 has L2/L3 and FEX support.
Take a look at this for more info - http://bradhedlund.com/2010/12/01/cisco-nexus-7000-connectivity-solutions-for-cisco-ucs/
And this for info on the gen 2 F2 cards - http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/data_sheet_c78-685394.html

Nexus 1000v UCS Manager and Cisco UCS M81KR

Hello everyone
I am confused about how works the integration between N1K and UCS Manager:
First question:
If two VMs on different ESXi and different VEM but in the same VLAN,would like to talk each other, the data flow between them is managed from the upstream switch( in this case UCS Fabric Inteconnect), isn'it?
I created a Ethernet uplink port-profile on N1K in switch port mode access(100), I created a vEthernet port-profile for the VM in switchport mode access(100) as well. In the Fabric Interconnect I created a vNIC profile for the physical NICs of ESXi(where there are the VMs). Also I created the vlan 100(the same in N1K)
Second question: With the configuration above, if I include in the vNIC profile the vlan 100 (not as native vlan) only, the two VMs can not ping each other. Instead if I include in the vNIC profile only the defaul vlan(I think it is the vlan 1) as native vlan evereything works fine. WHY????
Third question: How it works the tagging vlan on Fabric interconnectr and also in N1K.
I tried to read differnt documents, but I did not understand.
Thanks

This document may help...
Best Practices in Deploying Cisco Nexus 1000V Series Switches on Cisco UCS B and C Series Cisco UCS Manager Servers
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-558242.html
If two VMs on different ESXi and different VEM but in the same VLAN,would like to talk each other, the data flow between them is managed from the upstream switch( in this case UCS Fabric Inteconnect), isn'it?
-Yes. Each ESX host with the VEM will have one or more dedicated NICs for the VEMs to communicate with the upstream network. These would be your 'type ethernet' port-profiles. The ustream network would need to bridge the vlan between the two physicall nics.
Second question: With the configuration above, if I include in the vNIC profile the vlan 100 (not as native vlan) only, the two VMs can not ping each other. Instead if I include in the vNIC profile only the defaul vlan(I think it is the vlan 1) as native vlan evereything works fine. WHY????
- The N1K port profiles are switchport access making them untagged. This would be the native vlan in ucs. If there is no native vlan in the UCS configuration, we do not have the upstream networking bridging the vlan.
Third question: How it works the tagging vlan on Fabric interconnectr and also in N1K.
- All ports on the UCS are effectively trunks and you can define what vlans are allowed on the trunk as well as what vlan is passed natively or untagged. In N1K, you will want to leave your vEthernet port profiles as 'switchport mode access'. For your Ethernet profiles, you will want them to be 'switchport mode trunk'. Use an used used vlan as the native vlan. All production vlans will be passed from N1K to UCS as tagged vlans.
Thank You,
Dan Laden
PDI Helpdesk
http://www.cisco.com/go/pdihelpdesk

Cisco UCS FC Direct Attach Question

We are looking at the Cisco UCS as a replacement for our existing servers and SAN switches. As I understand the fabric interconnect can replace our existing SAN switches and that we will still be able to zone the ports just like we do on our SAN switches today.
Can someone confirm how using the fabric interconnects as a replacement for our SAN switches will work? I read that the fabric interconnects have to be in switch mode for this to work. How does this affect the other connections we will have to our Ethernet network?
Thanks.

Q1: The 6120s run in NPV (N_Port Virtualization) mode which means it acts as a proxy for the blade vHBAs and doesn't participate in flogi (fabric logins). When a fabric switch runs in this mode it requires an uplink to a faber switch for flogi and zoning. Due to this you cannot direct attach the the 6120 to an array's front-end fiber ports.
Q2: Yes you can uplink the 6120 to a Brocade fabric as long as the Brocade supports NPIV.

Cisco UCS 6324 Fabric Interconnect Used as a FEX?

Hi,
Is it possible to use the Cisco UCS 6324 Fabric Interconnect as a FEX to uplink UCS 5108 Blade Chassis to Cisco UCS 6200 Series Fabric Interconnects? Thank you.

How does it work if I want to add a second 5108 to a pair of 6324's? Having the 6324's replace the IOM (FEX) modules is cool but would you need to buy IOM's for the second chassis and then use up either 4 x 10GB ports or the 1 x 40GB or would I need to purchase 2 more 6324's?
Thanks in advance.

Cisco Ucs upgrade from 1.4(3m) to 2.1(1a)

hi!!
I need to do an upgrade from 1.4(3m) to 2.1(1a)!
i've 3 chassis 5108 ( 6 fex 2104xp ) with server B200 M2 and B440 M2. i've two Fi 6120Xp in cluster mode.
i've check the prerequisite to upgrade but i've a question about default zoning;
iv'e brocade switch 5300 ( fw v6.4.1 ) attached to Fi 6120xp
i've SAN configured :
i've no other configuration under San Tab.
The documentation says:
"Default Zoning is Not Supported in Cisco UCS, Release 2.1(1a) Onwards.Default zoning has been deprecated from Cisco UCS, Release 2.1(1a) onwards. Cisco has not supported default zoning in Cisco UCS since Cisco UCS, Release 1.4 in April 2011. All storage connectivity that relies on default zoning in your current configuration will be lost when you upgrade to Cisco UCS, Release 2.1(1a) or a later release. We recommend that you review the Fibre Channel zoning configuration documentation carefully to prepare your migration before you upgrade to Cisco
UCS, Release 2.1(1a) or later."
Can i upgrade to 2.1 (

hi!!
I need to do an upgrade from 1.4(3m) to 2.1(1a)!
i've 3 chassis 5108 ( 6 fex 2104xp ) with server B200 M2 and B440 M2. i've two Fi 6120Xp in cluster mode.
i've check the prerequisite to upgrade but i've a question about default zoning;
iv'e brocade switch 5300 ( fw v6.4.1 ) attached to Fi 6120xp
i've SAN configured :
i've no other configuration under San Tab.
The documentation says:
"Default Zoning is Not Supported in Cisco UCS, Release 2.1(1a) Onwards.Default zoning has been deprecated from Cisco UCS, Release 2.1(1a) onwards. Cisco has not supported default zoning in Cisco UCS since Cisco UCS, Release 1.4 in April 2011. All storage connectivity that relies on default zoning in your current configuration will be lost when you upgrade to Cisco UCS, Release 2.1(1a) or a later release. We recommend that you review the Fibre Channel zoning configuration documentation carefully to prepare your migration before you upgrade to Cisco
UCS, Release 2.1(1a) or later."
Can i upgrade to 2.1 (

ISCSI- Adding iSCSI SRs to XS booting via iSCSI [Cisco UCS]

Hello all-
I am currently running XS 6.0.2 w/ HF XS602E001 & XS602E002 applied running on Cisco UCS B200-M3 blades. XS seems to be functioning ok, except that i cannot see the subnet assigned to my SAN, and as a result, i cannot add any SR for VM storage.
The subnet and vNIC that i am configuring is also used for the iSCSI boot.
The vNIC is on LAN 2 and is set to Native
The SAN is a LeftHand P4300 connected directly to appliance ports (LAN2) on the Fabrics
Used the following commands during installation to get the installer to see the LUN.
echo "InitiatorName=my.lun.x.x.x" > /etc/iscsi/initiatorname.iscsi
/opt/xensource/installer/init --use_ibft
If i missed anything or more info is needed, please let me know.

Thanks Padramas,
I have 2 NICs that show up in XenCenter. Nic A is the vNIC associated with VLAN1 and provide the uplink to the rest of the network. The second NIC in XenCenter matches the MAC of the vNIC used to boot XenServer, so the NIC used for booting the OS is visible in XenCenter.
I have tried many different thing on my own to resolve this issue. I believe i have already tried adding a 3rd vNIC to the service profile for VM iSCSI traffic, but with make another attempt.
When configuring the vNIC for VM iSCSI traffic, do I only need to add the 3rd vNIC, or do i need to create both a vNIC and second iSCSI vNIC with Overlay vNic pointing to newly created (3rd) vNIC? My understanding is that the iSCSI vNICs are only used for booting, but I am not 100% sure.
Thanks again for the help!

Windows 2008 R2 on Cisco UCS B200M networking problems

This is driving me completely nuts. Let me start by saying I am new to blade servers and Cisco UCS. I did take an introduction class, and it seemed straight-forward enough. I have a chassis with two B200M blades, on which I am trying to configure two Windows 2008 R2 servers, which I will eventually make Hyper-V servers. This is all in a test environment, so I can do anything I want to on them.
Right now I have installed W2008 directly on hard disks on the B200M hardware.
The problem is this: even though I think I've configured the network hardware correctly, using the Cisco VIC driver software, I cannot get networking to work in any reliable way. I cannot even get ping to work consistantly. I can ping my local server address, but I cannot ping my gateway (HSRP address). When I try, I get a "Reply from 10.100.1.x: Destination host unreachable (x being each particular server's last octet). I CAN, however, ping the individual IP addresses of the core switches. I can also ping some, but not all, the other devices that share the servers' subnet. There are no errors being generated, the arp tables (for those devices I can ping) look good, netstat looks OK. But I cannot get outside the local subnet...
Except when I can.
There are times when I can get all the way out to the Internet, and I can download patches from Microsoft. When it works, it works as expected. But if I reboot the server, oftentimes networking stops working. Yet another reboot can get things going again. This happens even though I've made no changes to either the UCS configs or the OS.
I cannot figure out any reason when it works at some times and not at others. I've made sure I have a native VLAN set, I've tried pinning to specific ports on the Fabric Interconnects. There is just no rhyme or reason to it.
Anyone know of where I can look? I'm very familiar with Windows on stand-alone boxes (although it's no longer my area of expertise), and I manage a global WAN (BGP, OSPF, Nexus 7k, etc.) so I'm no dummy when it comes to networking, but I am utterly stumped on this one.

The problem was this: while the NICs on the blade server are called vNIC0 and vNIC1, Windows was calling vNIC1 "Local Area Connection" and vNIC0 "Local Area Connection 2". So what I configured on UCS did not match what I was configuring in Windows. Completely, utterly ridiculous.
Anyway, networking is working now without any issues. Thanks for you suggestion; it did get me looking in the right direction.

Cisco UCS 6120XP uplink considerations

Similar Messages

Maybe you are looking for