Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

UCS Connectivity issues.

 We have 2 Nexus 5548 and the UCS 6100 is homed to both with a port channel. We need to replace a 5548. When we unplug the UCS connection from that 5548 we lose the UCS totally. Even though it is still connected to the other 5548. Anyone seen this before or know enough about UCS to formulate a possible reason? One 5548 has 2 links in port-channel configuration to Fabric-A and the other 5548 is connected the same way to Fabric-B.   I am assuming there is something in the UCS that is not happening. The UCS admin assures me the failover tests he performs works from the UCS.

  • Unified Computing
12 REPLIES
Cisco Employee

Hi,I have a suspicion on the

Hi,

I have a suspicion on the network control policy. (Lan tab)

By default the action on uplink fail is set to link-down can you set it to warning and check?

Thanks,

Majid

VIP Red

I think something is not

I think something is not setup properly, either on N5k or the UCS FI;

see eg

http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white_paper_c11-623265.html

Figure 9

If one fabric goes down, be it the N5K or the FI, the other fabric should still be available, assuming that your teaming (Ethernet) or multipathing (Fibrechannel) is properly configured.

New Member

Sadly I am not not have the

Sadly I am not not have the information as to what they are doing on the UCS as of yet. I do know the network control policy is set to warning though. I also know the 5k config is solid that is simple.

interface port-channel15
  description UCS_6100
  switchport mode trunk
  switchport trunk allowed vlan xxx-xxx
  spanning-tree port type edge trunk
  speed 10000

interface Ethernet1/15
  description UCS_6100
  switchport mode trunk
  switchport trunk allowed vlan xxx-xxx
  spanning-tree port type edge trunk
  channel-group 15 mode active

interface Ethernet1/16
  description UCS_6100
  switchport mode trunk
  switchport trunk allowed vlan xxx-xxx
  spanning-tree port type edge trunk
  channel-group 15 mode active

Which leads me right back the the UCS.

Cisco Employee

Which version of UCSM are we

Which version of UCSM are we running? 

Is vlan optimization count enabled?

The symptoms you describe lead me to believe that this could be due to defect CSCuf35678

https://tools.cisco.com/bugsearch/bug/CSCuf35678/?reffering_site=dumpcr

 

Thanks,

Majid

New Member

We are running 2.2.1b.

We are running 2.2.1b.

VIP Red

Do you really have 2 vPC

Do you really have 2 vPC between each Fabric Interconnect and the 2 N5K, and they are both up and running ?

New Member

They are not a vPC they are

They are not a vPC they are set up as Orphaned Ports.

VIP Red

Why ? it is best practise to

Why ? it is best practise to use vPC between UCS FI and N5K. I am almost sure, that your initial problem is not related to UCS, but to this strange PC connectivity.

New Member

This connectivity was

This connectivity was something that was in place prior to me. It was relayed to me that this was designed and installed by cisco and at the time was a Cisco "Best Practice" for the architecture in place. Not what the core architecture has turned into or as is currently stands. The 5K swap is part of that conversion. Hence the need to pull the old 5548P and replace it with a new 5548UP.

I will agree that the UCS connectivity does not meet current best practices based on the current Nexus designs. However let that not distract you.

From a Nexus standpoint if you lose a switch that should not stop the UCS from seeing the fabric drop and repining the VNICs to the other fabric. Then the fabric would send a GrARP to the switch that is still up and rehome those addresses to that switch.

Don’t confuse this with losing the peer link as that would indeed cause the same type of issue. Only the vPC role (secondary) switch would shut down vPC’s as well as all the L3 SVI's. The physical interfaces would remain up and the UCS would not see a down status. So it would keep trying to use the fabric to that Nexus. Essentially you would create a black hole for traffic leaving that fabric to the Nexus where it would have no L3 route to the next hop and just drop the traffic.

237
Views
0
Helpful
12
Replies