Network Native

Its my intuition to assume that building a PC benefits anyone who seeks to begin, sustain or improve a career in the information technology space. However, over the course of my career I've interacted with business roles adjacent to IT that don't see the value in PC building. I can still recall an interview I'd participated in years ago where I'd made some reference to my PC build at the time. My video card stopped working and I'd done some work to isolate that card as the problem and get the component replaced. Being naïve as I was back then, I had no clue that the person interviewing me didn't have a technical skill set. This is despite the product of the company being extremely technical. My story about discovering the problematic GPU carried no sway with the interviewer. My interviewer probably didn't know what a GPU was (This was several years before the current AI hype cycle). Years later I still find myself reflecting on that experience. In this blog ...

Esxtop is the standard way to determine what vmnic is supporting a virtual machines vnic on an ESXi hypervisor. This involves pulling up a command line interface on an ESXi server, running command esxtop, pushing the "n" key and reading the list of VMs to identify which switchport is mapped to which physical nic. I will show the screenshots to demonstrate it, however there is an alternative method. First, lets see the method I've described above.  In this blog, were working with an ESXi server named esx-01a.corp.local. We SSH to the server and run command "net-stats -l". Make note of the Port ID. Next, run command "esxtop". The default view of esxtop shows cpu and process metrics. For our use case, we want to see network statistics. Push the "n" key, then locate the two Port IDs noted previously. Alternatively, you can use the following CLI commands to find the VMs world ID (something like a process ID) and map that to a vmnic. First we use c...

In my personal journey to understand NSX, I've found the greatest understanding to come from the NSX Design Guide. As it so happens, when I decided to write this blog (Dec 30, 2022), I noticed VMware released a new design guide on December 5th. This gave the perfect opportunity to write new blog posts as they relate to topics in the design guide. My intention is to write a series of blog post that give concrete examples corresponding to the section headings in the design guide. The reader will hopefully get a better understanding of the ideas being conveyed in the design guide, and I get to flesh out my understanding of the topic by explaining it.  The NSX design guide can be found here:  https://communities.vmware.com/t5/VMware-NSX-Documents/VMware-NSX-T-Reference-Design/ta-p/2778093?attachment-id=110654 Starting on page 18, we've got an introduction to the NSX Architecture Components. To start, we've got the NSX management cluster. NSX can function with only a single NSX ...

While working at VMware I learned the value of capturing packets inside of an ESXi hypervisor. I used packet capture so frequently I memorized the commands. Let me explain the basics of ESXi packet capture in this post. A network engineer's most precise tool to figure out what is happening in the network is always going to be a packet capture. Fortunately, ESXi hypervisors make this easy. My baseline of comparison? Packet capturing on physical networking infrastructure, such as a Cisco switch. With Cisco, the process entails creating a monitor port, connecting a cable to the switch, attaching a computer with a packet sniffer and finally, collecting and analyzing the packets with an application such as Wireshark. With ESXi packet capturing, the most cumbersome aspect is remembering the incredibly long commands! My pcap (packet capture) commands can be referenced in VMware's official documentation: https://docs.vmware.com/en/VMware-vSphere/7.0/vsphere-esxi-vcenter-server-703-net...