Network Native

In this post, I will discuss NSX vSphere Installation Bundles (VIBs). When installing NSX, one must perform the action of "preparing" the ESXi host. To prepare the host, it means install the requisite NSX VIBs on the ESXi host. If you're coming from a purely networking background, you might be wondering, "What is a VIB"? VIBs are basically drivers, or bundles of software, that give ESXi enhanced or distinct software abilities. Even in cases where NSX is not installed, ESXi hosts will have VIBs installed to perform its day-to-day server virtualization functions.   Non-NSX VIBs List VIBs Command: esxcli software vib list To give the ESXi host NSX capabilities such as Network Function Virtualization, NSX specific VIBs must be installed on the host. During host preparation, the VIBs are pushed from the NSX-T Manager to the host. Lets take a look at those vibs and I'll give a description of what each of them do. You'll notice in the image below that the NSX V...

NSX-T is a vast product. On this occasion I want to take a crack at explaining NSX-T host preparation in a visually comprehensible manner. Host prep is the process where NSX-T manager will connect with your ESXi hosts and install VIBS, or VMware proprietary software packages (drivers). These vibs allow your hypervisor to participate in overlay networking, distributed firewall and a slew of other NSX-T features. After the NSX manager is installed and you have registered it with vCenter Server, host preparation is the next step. Not mentioned here are the steps to prepare a KVM host. Below: NSX-T U.I. showing successful registration with vCenter For this blog post, I'm going to use a nested ESXi host in my home lab. It has 3 vNic which are perceived as vmnics by the nested ESXi instance: Through the NSX-T UI, the unprepared ESXi host look like this: At this point, you could choose to apply a transport node profile, but to keep it simple we're not going to do that. Select the host...

I recently took some time off and wanted to learn a bit about how I might automate my job duties. One thing that I find myself doing every day is packet capturing network traffic for VMware virtual machines. I do it so often, I have the packet capture command structure memorized despite the fact its around 80 characters long. Even so, why not automate it? For those who want to go strait to the automation, check out my Githup pages : Packet capture script template: https://github.com/allend2092/BASH_SCRIPTS_VMWARE/blob/0acd67f24df3d398b34c7973ba8b5bc5a9c176e5/simultaneous_pcap_files Generate packet capture commands: https://github.com/allend2092/BASH_SCRIPTS_VMWARE/blob/0acd67f24df3d398b34c7973ba8b5bc5a9c176e5/make_pkt_cpt_commands.sh For a little more explanation, here are the resources a person can use to understand the packet capture commands for an ESXi hypervisor: https://docs.vmware.com/en/VMware-vSphere/7.0/vsphere-esxi-vcenter-server-703-networking-guide.pdf Page 224 has a headi...

  August 14th, 2021 With the ramp-up of NSX-T overlay networks and transition away from NSX-V overlay networks, it's a good time to look at one of the fundamental differences between them. NSX-V uses VXLAN as its encapsulation protocol while NSX-T uses the more recent GENEVE encapsulation protocol. Each require the physical networking devices have their MTU adjusted to 1600 bytes or greater. We'll take a detailed look at why that is. First, the basics: VXLAN is: short for Virtual eXtensible Local Area Network Is defined in rfc 7348 - https://datatracker.ietf.org/doc/html/rfc7348 Uses UDP port 4789 8 byte header GENEVE is: short for Generic Network Virtualization Encapsulation Is defined in rfc 8926 -  https://datatracker.ietf.org/doc/html/rfc8926 Uses UDP port 6081 16 byte header From the prospective of the physical network, an overlay network is essentially an application. NSX-T is an application using well known UDP port 6081. Switching perspectives to the overlay's...

  Network address translation, or more commonly NAT, is most often used to do source NAT or destination NAT. In rare instances, SNAT or DNAT isn't enough to get ip packets to their destination. Enter twice nat. While twice NAT isn't a function I've needed often, it was a function drilled into me while studying for various Cisco exams. I used to watch Christian Matei explain it over at INE and it really helped me to understand what twice NAT is and how to configure it on Cisco devices. Previous to my time working with NSX-T, I'd only utilized twice NAT once. A few years back, a customer wanted to build and IPsec tunnel from the organization HQ to a branch office. The private ip space used by HQ and the branch used overlapping ip space. We used twice NAT to NAT the source and destination ip address in a single NAT rule ( similar to this guy ) before shoving it all into an IPsec tunnel. Previous to working with NSX, circumstances requiring twice NAT were uncommon.  While w...