Category Archives: Cisco

Mission Accomplished!!! Now….do I retire??? + A Java Error!

First, I don’t know how many of you read the “About Me” pages on blogs….personally, I rarely do but on my About Me page, I stated that I was on a mission to “find my own blog while doing a random Google search.”

Yesterday, I was Googling for a good NetScaler/Access Gateway diagram and was led to a picture I took of a baby bird…in its nest…on my porch!


I don’t know what baby birds, NetScalers, and the Access Gateway have in common, but I was so pleased that some piece of my blog turned up while doing a random Google search!  And so today, having reached the pinnacle of the blogging experience, I’d like to officially announce my retirement from blogging.  Thank you for your support!  🙂

Second, I had a customer contact me today regarding an error when logging Cisco UCS Manager.  This was cause for concern, in fact, in their own words, they were “about to freak out on this one” thinking the admin password had been secretly reset.  And since I don’t want any of my customers freaking out, I wanted to help them out.

When logging into UCS Manager the error stated, “Login Error: Server returned HTTP response code 400”:


Naturally, like most things I feel I troubleshoot these days, this was nothing more than a Java….”mismatch”….I’m not sure what to call it.  Java was updated to version 8u45 on the computer being used to connect to UCS Manager; evidently this version of Java is too new for, or not compatible with their version of UCS Manager.  When connecting from a computer with Java 7u25 or below, the error was not displayed and UCS Manager opened without issue.  JAAAVVVAAA!!! (Think William Shatner screaming “KHAN!!” in Star Trek 2)

Now let me say this….to get around some of these issues, I have started using VMware ThinApp to create packages of specific browsers and Java versions.  This has somewhat kept me from pulling my hair out and spinning my wheels installing/uninstalling Java when I’m working with customers with different versions of Unisphere, UCS Manager, and all the other interfaces out there that require some version of Java.  If you have access to ThinApp, I recommend it for your use to workaround such issues.

P.S.  I’m not retiring….I’m sure the 4 of you who may read this will rest easy tonight.  🙂

Leave a comment

Filed under Cisco, VMware

Disabling IP Device Tracking to Avoid IP Conflicts

Recently, a customer had an issue where, upon reboot, Windows-based VMs hosted on vSphere servers would detect a duplicate IP address and then assign themselves IP addresses.  These VMs had been operating for years without issue so why is this taking place now?  The client had an interesting observation….that the problem started as soon as they migrated their vSphere hosts to Cisco Catalyst 3850 network switches.

The issue they were experiencing is basically identical to the one described in the VMware KB1028373 and the primary workaround is to turn off gratuitous ARP in the guest operating system using an ArpRetryCount registry key.  That workaround was attempted by the client before I was engaged but to no effect.

In speaking with network engineers, they were of the belief that IP Device Tracking was the culprit, not Gratuitous ARP but why?  Two reasons it seems, first Microsoft introduced (with Vista and above) a new mechanism to detect duplicate IP addresses and the Cisco 3850 switch is aimed more at the access layer level (so I’ve been told), and not necessarily configured out of the box for vSphere/VM functionality, though it can certainly be configured to serve as core/datacenter switches in smaller environments.

From Cisco TAC Article 116529:

Cisco IOS uses the Address Resolution Protocol (ARP) Probe sourced from an address of in order to maintain the IP device-tracking cache when IP device tracking and a feature that uses it is enabled (such as 802.1x) on a Cisco IOS switch.

Duplicate IP Address Cause

If the switch sends out an ARP Probe for the client while the Microsoft Windows PC is in its duplicate-address detection phase, Microsoft Windows detects the probe as a duplicate IP address and presents the user with a message that a duplicate IP address was found on the network for The PC does not obtain an address, and the user must either manually release/renew the address, disconnect and reconnect to the network, or reboot the PC in order to gain network access.

After some discussion, the decision was made to disable the IP Device Tracking feature altogether using the following commands….the example assuming (2) 48-port switches:

  • config t
  • !
  • int range g1/0/1-48, g2/0/1-48
  • nmsp attach suppress
  • end
  • !
  • copy run start

False duplicate IP messages have not appeared since making this change.

Leave a comment

Filed under Cisco, VMware

Replacing a failed 6248XP Fabric Interconnect

To date, I’ve not had to replace a running 6120XP Fabric Interconnect but just days ago, I had to replace a 6248XP Fabric Interconnect that had been configured as part of a FI Cluster. Not long after configuring my FI Cluster, FabricA started rebooting itself anywhere every 60-90 minutes. I called Cisco TAC and after a bit of troubleshooting, it was determined that the 6248 needed to be replaced. I was told that the field engineer would install the new fabric interconnect and re-create the FI cluster, but…when the field engineer arrived he said, “I don’t do configurations…”, thus began this post.

Replacing a Fabric Interconnect is not hard really, you just need to make sure its done right to make the changeover go smoothly. The high-level steps are as follows:

1. connect the new FI to the network (do not connect the L1 and L2 cables)

2. console into the new FI and run through the setup wizard configuring the new FI as a “standalone” fabric interconnect

3. Assuming the new fabric interconnect is not at the same code level as the current FI, open your internet browser and connect to the IP address assigned to the new FI, login as admin, and upload the UCS code that is installed on the cluster member.

4. Still connected to the new FI, update both UCS Manager and the Fabric Interconnect to the code running on the existing cluster member.

5. Once the upgrades are complete, verify the Running and Startup versions match those of the existing cluster member.

6. Console into the new fabric interconnect and run the following commands:
:connect local-mgmt
:erase configuration
:yes (to reboot)

7. Connect the L1 and L2 cables to the existing fabric interconnect

8. Console into the new fabric interconnect and run through the setup wizard. When the setup wizard detects the presence of a peer Fabric interconnect, type y to add the new FI to the existing cluster. Save the configuration and reboot the new FI.

9. Login to UCS Manager or use the command line to verify the cluster state.

10. Test failover. In this example, I use the command line on Fabric-B as Fabric-A was the “new” fabric interconnect. From the command line of Fabric-B, enter the following commands:
:connect local-mgmt
:show cluster state (verify B is still the primary)
:cluster lead a (makes Fabric-A the primary)
:show cluster state (if done quickly, you’ll see the status of SWITCHOVER IN PROGRESS)

11. Login to UCS Manager once again to verify the failover is seen in the GUI and you are done.


Filed under Cisco