Network Native

 "MTU refers to the maximum size of an  IP packet  that can be transmitted without fragmentation over a given medium." - https://en.wikipedia.org/wiki/Maximum_transmission_unit   Over the years, working with customers to resolve MTU issues with NSX overlay networks called attention to my weakness in understanding MTU and its implications. My experiences troubleshooting and experimenting with MTU are the inspiration for this blog post. I’ve needed to strengthen my knowledge on MTU because VXLAN network traffic requires a network to transport data frames with 1600 byte MTU at a minimum. The standard MTU in TCP/IP networking devices is 1500 bytes. This has been the standard since the birth of the Internet, which I'm going to define here as the decade TCP/IP protocol was invented, the mid 1970s . MTU is a well documented network attribute. However, reading documentation about MTU didn’t prepare me to understand the implications of changing MTU and how to troubleshoot

This lab / tutorial will show you the path of an IP packet that is routed through an NSX distributed logical router (DLR). This is often one of the most difficult components to conceptualize, particularly for network engineers who have experience with traditional routing using physical routers. My hope is that by going through this lab, it will help clarify the ways in which a DLR is the same as traditional routing, and the ways in which it is different from traditional routing in physical routing devices. Let's get started! Step 1: Head over to http://labs.hol.vmware.com/ and type nsx in the search bar. Click to enroll in the lab below. Use this HOL: Step 2: Run powershell script 3 & 4. This removes some Distributed Firewall (DFW) configuration that exists to show users how to manage the DFW. Here we are not concerned about the DFW: Step 3: Open the browser. It should load the vSphere web client to the login screen. login with the following credentials: administrat

Often, when helping customers isolate and resolve problems with NSX-V or with HCX ( hybrid cloud extensions ), a redeploy is the best option to fix the problem. When I propose a redeploy, I can sense fear gripping the recipient of the suggestion. I understand the initial fear, because coming from a hardware networking background, I recognize it takes time for NSX-V users to grasp the advantages of software networking over physical networking. Redeploying a hardware router, switch, or firewall is not a small ordeal. You'll need to procure the new device, copy the configuration from old to new, then swing the cabling over from old to new device during a planned maintenance window. With NSX-V, this process happens in a matter of minutes, in an automated fashion, at the literal click of a button. Human error is minimized due to automating the process. For the speed readers, here is the TL;DR of the NSX-V redeploy process: 1. Click Redeploy. 2. vCenter builds out a new VM that lives