Networking

Last Tuesday I had the privilege of presenting an introduction to the NSX APIs on vBrownBag EMEA - you can view the recording below or on vBrownBag’s youtube channel.

During the presentation I showed a mind map of the API, which I’ve made

available on GitHub in PDF format

I’ve also published the Postman collection and environment I used during the demonstration, which covers some basic configuration and deploy tasks:

Providing a highly available single sign on for vRealize Automation is a fundamental part of ensuring the availability of the platform. Traditionally, (vCAC) vRA uses the Identity Appliance and relies on vSphere HA to provide the availability of the SSO platform, but in a fully distributed HA environment that’s not really good enough. It’s also possible to use the vSphere 5.5 SSO install in a HA configuration - however, many companies are making the move to the latest version of vSphere and don’t necessarily want to maintain a 5.5 HA SSO instance.

I am aware that that’s not a catchy blog post title. In fact, it doesn’t even really describe the problem or solution very well - for that I need to go into a little bit more depth!

Suppose I have configured a Reservation with two Networks ticked (“192.168.1.0-VLAN1” and “192.168.10.0-VLAN10”). As you can see in the screenshot below, each of the networks has a Network Profile created and assigned with a network pool to provide IP addressing for the VMs.

I recently got my hands on a copy* of Chris Wahl and Steve Pantol’s Networking for VMware Administrators and was very keen to read it – especially given the reputation of the authors. I came to the book as someone who is at CCNA level (although now expired) and someone who regularly designs complex VMware networks using standard and distributed switches. I would class myself as having a fairly decent understanding of networking, though not a networking specialist.

Today was always going to be a bit of a funny day as I scheduled the VCAP5-DCD exam for 10am this morning. I am happy to say that I passed! I’m a bit light on VMworld to report today, so forgive my DCD experience to pad it out!

Preparation

I have to confess my prep for this exam was light – I literally only watched the TrainSignal course by Scott Lowe (@scott_lowe) and just about finished that last night in the hotel! I don’t spend much time focussing on design during my day job, so I approached this exam as a bit of a learning experience rather than a serious bid to pass. I decided to book the exam here at VMworld just because you can get 75% off – if you’re funding yourself it’s not a discount to be dismissed easily!

As some of you read previously, I had been experiencing disk latency issues on our SAN and tried many initial methods to troubleshoot and understand the root cause. Due to other more pressing issues this was placed aside until we started to experience VMs being occasionaly restarted by vSphere HA as the lock had been lost on a given VMDK file. (NOT GOOD!!)

The Environment:-

So, you’ve installed a new server with Server 2008 R2 Core – what next? Logging on, you’re presented with a shiny command prompt, you can run notepad or regedit…but aside from that, where do you go from there? In the next few series of posts I’ll hopefully point out the basics, and some not so basics!

Using the Server Configuration Tool

The server configuration tool (sconfig.cmd) is provided in R2 for some of the basic setup tasks, so you can run that by issuing the “sconfig” command. Out of the box, it looks something like this:

No matter how good your network diagrams are, sometimes you need to verify the port your server/desktop is in. Cisco Discovery Protocol is a great tool for network admins when you need to quickly map routers and switches, and if you’ve got an ESX server connected you’ll see that it picks up CDP info too – but the vast majority of my managed systems are Windows.

Here’s how to use TCPDUMP by Micro Olap to extend that functionality to your Windows boxes.

Here’s the setup. We have a core switch of 2 Cisco 3750s, connected together for fault tolerance as a single logical switch; we also have several ESX 3.5 hosts with 4 Gigabit Ethernet NICs installed each. The Virtual Machines will all be on VLAN 8 (reserved for internal servers) and the VMKernel will be on VLAN 107 (reserved for VMKernel traffic like VMotion).  I want to create a load balanced, fault tolerant aggregate of these four NICs over the Core Switch.

I recently resolved an ongoing DNS issue where the Active Directory Integrated DNS was loaded in both the Domain and the DomainDNSZones partition of AD - this is a separate issue and should be resolved differently. My problem when I tried to verify that the fixed DNS setup had propogated around my domain controllers, DC01 and DC02. DC01 kept failing “DCDIAG /TEST:DNS” with errors regarding the root hint servers. Googling about it was clear that a lot of people were suffering the same issue, but no article I read had correctly identified the solution.