NSX-V Load Balancer: Inline vs One-arm

 

NSX-V Load Balancer: Inline vs One-arm

In this post I am going to talk about the NSX-V load balancer. In particular, I wanted to talk about the difference between inline and one-arm architecture versus inline and one-arm configuration. I chose to blog about this because it seems to confuse many of my customers. I also found it quite confusing at first since the documentation doesn't provide enough detail to build an intuition on how the architecture and configuration work together to make a functioning load balancer. However, the NSX documentation is a good starting point.

NSX-V's Administration Guide on page 315 explains the basics about the load balancer:

https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSphere/6.4/nsx_64_admin.pdf


This time around I decided to demonstrate how one-arm load balancer configuration and one-arm architecture differ, as well as inline configuration and inline architecture differ. Click this link below for my youtube video.



Loadbalancer Lab Network Diagram






Inline / Transparent Load Balancer architecture and packet flow:


Inline / Transparent load balancer configuration:

One-Arm Load Balancer architecture and packet flow:


One-arm load balancer configuration:


I'm trying not to be so wordy here since I also created a video. The main take away is that its possible to arrange the load balancer in a one-arm architecture, but have the server pool configured as transparent (a.k.a inline), and it still might forward traffic to the end user as expected. Conversely (and more frequently), you can arrange the load balancer in an inline architecture and have the server pool configured as a one-arm. The load balancer will happily forward traffic to the server pool despite the mismatch between architecture and configuration. The problem with this mismatch of configuration and architecture matters when the application isn't working correctly and you have to troubleshoot the load balancer. Understanding the architecture and the configuration makes troubleshooting and implementation much more strait forward. Hopefully this blog will clear things up in that regard.   











Comments

Post a Comment

Popular posts from this blog

VXLAN versus GENEVE (NSX-V vs. NSX-T)

Image
  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...
Read more

"Twice NAT" with NSX-T T0 Gateway

Image
  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...
Read more

Packet Capture Network Traffic Inside ESXi Hypervisor

Image
The three components of computer infrastructure are considered compute, storage, and networking. When applications don't work properly, its often the case that networking is the first component to receive blame for failed application performance. In the case of virtualized workloads (i.e. applications running on virtual machines), we are fortunate to have a powerful troubleshooting tool which allows us to packet capture network traffic in an ESXi hypervisor. For this blog, I'm going to use an Hands On Lab (HOL) from the VMware website to demonstrate the process of doing a quick live packet capture. The output of the packet capture will be sent to the shell of the hypervisor. There are ways to sent the network traffic to a file so it can be extracted and analyzed by a packet analyzer tool, but that will be for another post. First, lets start with heading over to the HOL website:  https://labs.hol.vmware.com/ For this lab, I'm going to type NSX in the search bar to find...
Read more