UCS API / CLI Authentication, Specifying an authentication domain

When an authentication domain defined on the UCS system, to facilitate LDAP or other authentication sources, the following username will allow login to the non-default authentication domain for the API and CLI:

  •  ucs-<authentication_domain_name>\username

Obtained from https://communities.cisco.com/thread/45154

pfSense on Watchguard and Useful LED lights

I recently setup pfsense embedded on an old Watchguard x750e for my home lab.  It works great!  Lots of community support for this.

For fun, I configured the front LED to change status depending on the results of a ping test.  I can glance at the box and verify basic Internet connectivity… specifically, can I ping Google’s public DNS system?  Yes is green, no is red.

I’m using WGXepc to set the fan speed down to something reasonable, and it can also control the front LEDs.

NOTE: On pfSense embedded make sure you set the filesystem to read-write first (/etc/rc.conf_mount_rw) and back to read-only when done (/etc/rc.conf_mount_ro).

I wrote “test-host-set-led.sh” to test ping to 8.8.8.8 for about 50 seconds, 1 ping / 5 seconds.

For testing, I set the IP to a non-responsive IP:

Placed the test-host-set-led.sh file in /usr/sbin/ and set it to executable:

And created a cron job to run this script every minute, using the CRON package.

That’s it! Done.

Audit VM and Host Time Sync

As a best practice, UCS systems should be configured to use a central NTP server for time.  Before making this change to customer UCS systems, I verify the current relationship of timekeeping between the UCS system and VMs.  This is necessary to understand the impact of the UCS-level NTP reconfiguration.

In the script below, I query each ESXi host and determine:

  • Current ESXi host time
  • Current ESXi time zone
  • A list of NTP servers specified on the host

This helps me identify ESXi hosts that may be impacted by a bare-metal time change.

Finally, I query the list of VMs looking for any machines that sync time with the host.  The intersection of the list of hosts impacted and list of VMs that sync time is my potential for service impact.

A more elegant way of doing this would be to query for ESXi hosts that aren’t actively using an NTP server or have invalid time, and then list the VMs running on that host and whether they sync time with the host.  But I am generally dealing with a small number of objects at the moment, so this has been sufficient for now.

This one-liner is necessary if any of the ESXi hosts get their time from the bare-metal blade instead of an NTP server.  If so, then these VMs could be impacted by a time change on the bare-metal blade.

UCS Specify Order for Primary/Secondary DNS or NTP Servers

While configuring a UCS system, I had a customer question how to specify a primary and secondary server for DNS, and also for NTP.

Answer: You don’t.

As far as I can tell, when you set multiple DNS servers, or multiple NTP servers, UCS will alternate between each.

My usual approach of using Google knowing everything failed to yield any results, so time to fire up the UCS Platform Emulator…

From the UCS GUI:

1

From the UCS CLI:

2

Creating two DNS server entries in order, 8.8.8.8 first:

3

Then, I deleted this config and recreated in reverse order:

4

Same result.  So the order of creation doesn’t impact the order the servers are listed.

So, how about a network trace?  Since ESXi 5.5 includes the ability to capture traffic for an individual VM, this was pretty easy to do:

Find the virtual port ID for the UCS Emulator (this corresponds to vNIC 0 on the UCS PE VM from the Cisco OVA)

5

Start a packet capture for 2K packets:

6

After downloading the .pacp file, I filtered the results in Wireshark and Voila!  The UCS alternates between each specified DNS server.

7

I observed similar results after setting multiple NTP servers, but I will spare you the screenshots.

Bottom line – just configure multiple DNS/NTP servers, and don’t worry about the rest.

Verifying many VLAN/subnets on a ESXi host

This script is designed to automate the network validation testing that is often required when standing up a new ESXi host, to verify that the host can reach each VLAN/subnet it is supposed to reach.

The script works by reading a CSV file listing network and VLAN ID information, and then creating a temporary port group and VMKernel port on each VLAN ID with the appropriate IP address and subnet mask.  It then pings the specified gateway IP and returns the result in summary format.

It is fairly robust as far as execution goes – if interrupted, it can just be run again.

Running it with $automatedExecution = $true will run through all the tests and report the summary.  The default mode, $automatedExecution = $false, will prompt at each significant action, giving you a pause to troubleshoot if something goes wrong.

Create a CSV file following this format

Then run this script, passing the appropriate parameters (they are self explanatory).

Recent Posts

Categories

Archives

GiottoPress by Enrique Chavez