Yellow Bricks

by Duncan Epping

Standby NICs in an “IP-Hash” configuration

· ·

I was reviewing a document today and noticed something that I’ve seen a couple of times already. I already wrote about Active/Standby set ups for etherchannels a year ago but this is a slight different variant. Frank also wrote a more extensive article on it a while and I just want to re-stress this.

Scenario:

  • Two NICs
  • 1 Etherchannel of 2 links
  • Both Management and VMkernel traffic on the same switch

I created a simple diagram to depict this:

nics

In the above scenario each “portgroup” is configured in an active/standby scenario. So let’s take the Service Console. It has VMNIC0 as active and VMNIC1 as standby. The physical switch however is configured with both NICs active in a single channel.

Based on the algorithm that etherchannels use either of the two VMNICs will accept inbound traffic. The Service Console however will only send traffic outbound via VMNIC0. Even worse, the Service Console isn’t actively listening to VMNIC1 for incoming traffic as it was placed in Standby mode. Standby mode means that it will only be used when VMNIC0 fails. In other words your physical switch will think it can use VMNIC1 for you Service Console but your Service Console will not see the traffic coming in on VMNIC1 as it is configured in Standby mode on the vSwitch. Or to quote from Frank’s article…

it will sit in a corner, lonely and depressed, wondering why nobody calls it anymore.

High physical switch CPU load?

· ·

One of my customers experienced high CPU load on their physical switch. After some investigation they noticed broadcasts packets being sent every two seconds. The first reaction was Beacon Probing is probably enabled.

Unfortunately this wasn’t the case. But VMware GSS came to the rescue and pointed us towards a KB article. Apparently a bug has been identified in 4.0 which causes this behaviour:

src: http://kb.vmware.com/kb/1024435

Problem:

  • ESX sends Beacon Packets when vDS/vSwitch are connected to more than one uplink.
  • ESX server sends periodic broadcast of Beacon Packets even if the vSwitch/vNetwork Distributed Switch (vDS) is not configured to use Beacon Probing for Network Failover Detection.
  • These packets have the virtual MAC of the vmnic in the Source MAC Address field.

Workaround:

#esxcfg-advcfg -s 0 /Net/MaxBeaconsAtOnce

The customer implemented this workaround and the problem is gone… From what I have been told this issue does not exist in ESX(i) 4.1 so if you are experiencing it, an upgrade might be a better solution. In this case due to the size of the environment that was not an option.

HA Cli

· ·

I was just playing around with the HA Cli and noticed that when you give an “ln” (listNodes) that the failover coordinator (aka master primary) is also listed. I have never noticed this before, but don’t have a pre-vSphere 4.1 environment to test it on to see if this existed before 4.1. If you want to test it in your own environment just simply run “/opt/vmware/aam/bin/Cli” and give the “ln” command as shown in the screenshot below:

I also tested demoting of a node just for fun. In this case I demoted the node “esxi1” from primary to secondary:

And of course I promoted it again to primary:

 

** Disclaimer: This article contains references to the words master and/or slave. I recognize these as exclusionary words. The words are used in this article for consistency because it’s currently the words that appear in the software, in the UI, and in the log files. When the software is updated to remove the words, this article will be updated to be in alignment. **

Changing your dvPortgroup settings? (need your input!)

· ·

I am just wondering if I am the only one who doesn’t understand this. I had a discussion with our vDS team around changing the dvPortgroup settings. This can only been done after the dvPortgroup has been created. On top of that it gets created with standard values of which some don’t really follow my general best practices. (For instance Forged Transmits is set to Accept by default instead of Reject.)

With a regular vSwitch you could just set all your preferences on the vSwitch. The Portgroups that you would create would inherit the properties of the vSwitch. Of course when needed you could always override these properties on a per Portgroup level. However with a dvSwitch this isn’t possible as you cannot set these properties on the dvSwitch level. A dvPortgroup however is created with default settings which you can’t change during the creation.

Apparently this decision has been made after many customer complained about the complexity of the vSwitch / Portgroup inheritance concept. I have never found this a problem, or even complex to be honest and I was wondering what you think about this?

Do you prefer the current method or would you for instance like to have the option to change the defaults? I think having a “default dvPortgroup template” would be a nice enhancement. Please leave a comment and I will, if needed, contact our Product Manager to discuss this and will do my best to get it on the roadmap.

VMworld San Francisco Run 2010

· ·

In 2009 I was one of the people who came up with the idea to run the Golden Gate Bridge during VMworld. This idea got a little out of hand and we ended up with roughly 200 runners and 4 Sponsors. It was probably one of the best social events I ever attended during VMworld.

This year we expected that a lot more people wanted to join and as such the VMworld Organization is running (:-)) the event this year.

src

What: 5k out-and-back course
When: Sunday, August 29th at 5:00 p.m.
Where: Crissy Field, San Francisco
Who: VMworld 2010 attendees and spouses
How: Registration and further information to come out next week.