Posts tagged NEXUS

vSphere ESXi 4.1 U1 NIC Teaming Cisco Nexus vPC

0
September 22, 2011
by Michael McNamara in

I had a very interesting problem this past week that I thought I would share and even seek comment on. We have quite a few vSphere ESX 4.0 and even vSphere ESX 4.1 hosts running in our network. This past week we installed 2 HP DL-380 servers with vSphere ESXi 4.1 Update 1 and we immediately noticed an issue with NIC teaming on the management interface (vmk0). We were connecting the ESXi 4.1 hosts to a pair of Cisco Nexus 7010 switches over a virtual port-channel (vPC). I should comment that this is our first ESXi deployment, all previous VMware deployments had been ESX.

Loss of connectivity

In the past we’ve taken different approaches with respect to how to configure the core/distribution network switches when connecting them to ESX servers for NIC teaming. In some instances we’ve created SMLTs, MLTs (Nortel/Avaya) or vPCs, PCs (Cisco) depending on the location and equipment. In this instance no matter how we configured the switch port we would always loose network connectivity to the management interface the moment we brought up the second NIC. We had VMware ESX 4.1 hosts running from the exact same Cisco Nexus 7010s so I was at a loss to immediately explain the problem.

Solution – VMware KB Article

Thankfully I’ve become a master (as many have many other technical folks) in the use of Google and pretty quickly stumbled across VMware KB article 1022751 entitled, NIC teaming using EtherChannel leads to intermittent network connectivity in ESXi.

When trying to team NICs using EtherChannel, the network connectivity is disrupted on an ESXi host. This issue occurs because NIC teaming properties do not propagate to the Management Network portgroup in ESXi. When you configure the ESXi host for NIC teaming by setting the Load Balancing to Route based on ip hash, this configuration is not propagated to Management Network portgroup.

I’ll be the first to admit that I haven’t spent too much time with ESXi, but seeing that VMware has already commented the ESX will be going way I probably need to do some catching up.

Cheers!

Cisco Nexus Switch Backups with Perl SNMP

24
September 1, 2010
by Michael McNamara in

I’ve spent some time over the past few days trying to get our home grown Perl script designed to backup all our network switches to work with the Cisco Nexus 7010 and 5010 switches.

With previous Cisco switches such as the 6509, 3750, 2960, etc we know that the following commands (when sent via a Perl script using the Net-SNMP Perl module) would instruct the switch to copy it’s running-config to a TFTP server.

snmpset -v1 -c$COMMUNITY $HOST ccCopyProtocol.$RANDOM i 1
snmpset -v1 -c$COMMUNITY $HOST ccCopySourceFileType.$RANDOM i 4
snmpset -v1 -c$COMMUNITY $HOST ccCopyDestFileType.$RANDOM i 1
snmpset -v1 -c$COMMUNITY $HOST ccCopyServerAddress.$RANDOM a "10.1.1.50"
snmpset -v1 -c$COMMUNITY $HOST ccCopyFileName.$RANDOM s "sw-train-acme.cfg"
snmpset -v1 -c$COMMUNITY $HOST ccCopyEntryRowStatus.$RANDOM i 1
sleep 5
snmpget -v1 -c$COMMUNITY $HOST ccCopyState.$RANDOM
#if not successful sleep 3 and re-check ccCopyState else continue and destroy table entry
snmpset -v1 -c$COMMUNITY $HOST ccCopyEntryRowStatus.$RANDOM i 6

I know that the both the Cisco Nexus 7010 and 5010 both balk at the SNMP OIDS/MIBS used above. So I’m searching for a set of equivalent SNMP OIDS/MIBS as those in CISCO-CONFIG-COPY-MIB for NX-OS. I’m not sure that such a OID/MIB even exists for NX-OS but it doesn’t hurt to search and ask.

I’m curious if anyone else has come across this issue? I know that there is an XML interface available but I would prefer to keep using the PERL/SNMP script that I’ve already developed. In the interim I’ll probably write an Expect script (or add some Expect code to my existing Perl script) to remotely connect to the switches and issue the appropriate copy commands.

Cheers!

Updated: Monday June 27, 2011

I’ve finally found the issue and now I’m able to backup the Cisco Nexus switches as expected.

New Data Center – Tidbits

2
June 15, 2010
by Michael McNamara in ,

I thought I would follow-up my last post with some additional tidbits and background on the data center build.

Let me start by saying that we haven’t abandoned Nortel/Avaya as a viable network electronics vendor. When we first started this effort back in January 2009 we initially looked at Brocade, Cisco, HP, Juniper and Nortel. After the initial cut we were left with Brocade, Cisco and Nortel/Avaya. When the final decision was made, back in November 2009, there was still a lot of concern about Avaya’s purchase of Nortel’s Enterprise Division so the decision really came down to Brocade or Cisco. Ultimately the decision was made to go with Cisco. As I commented in the previous post we still have well over 33,000 ports on Nortel/Avaya switches and less than 1,000 ports on Cisco switches. We are still purchasing and installing/deploying Nortel/Avaya switches in our hospitals and business offices .

Nexus 5010 Virtual PortChannel bug?

I’ve been known to tell people that we’re a partner with Nortel/Avaya because of the number of bugs that we identify and help to resolve.  Well if I thought it was going to be any different with Cisco I can throw that idea right out the window as we have identified a bug in the vPC code for the Nexus 5000 switch. We discovered the issue with a pair of Nexus 5010 switches when one of the switches up and died (hardware failure). While trying to troubleshoot the problem we restarted the remaining Nexus 5010 switch only to find that the remaining Nexus 5010 would no longer adopt the Nexus 2148 switches/FEXes after it was rebooted if the peer Nexus 5010 wasn’t online. If we removed the vpc configuration from the portchannel then the FEX would come online. After speaking with Cisco they have created bug CSCth01969 which is supposedly going to be addressed in the next software release.

HP Virtual Connect Flex-10/NIC issues/ESX 4.0 Update 1 Drivers

We also ran into a number of issues with the HP BL490c blades and HP Virtual Connect Flex-10 Interconnect. On a number of blades we had an issue where the ESX installer was unable to locate any network interfaces. The installer would error with something like “The script 32.networking-drivers failed to execute and the installation can not continue.” The solution was to re-apply the NIC firmware after the Virtual Connect profile had been applied to the server. You can find additional detail over at Brian’s blog if interested.

We also ran into another issue when performing our redundancy and high-availability testing. We configured Virtual Connect to use SmartLink, however, when we unplugged the uplinks from the B side interconnect the Virtual Connect Flex-10 interconnect didn’t disable the server side NICs. The solution to this problem was to update the NIC driver that shipped with ESX 4.0 Update 1. You can find the driver here.

Lots of additional stories to come including a comparison of vPC and SMLT.

Cheers!

Go to Top