➡️ Early-Bird Registration Is Open for VMware Explore Europe! VMware Explore 2022 Europe | Barcelona, Spain; 7 – 10 November 2022
I am delighted to announce an updated version of the vSAN Deep Dive book. It’s been a while since we did an update to this book. The most recent version was for vSAN 6.7 U1. A lot has changed since then. We’ve seen the arrival of some significant features such as vSAN File Service and HCI-Mesh.
The data center landscape has radically evolved over the last decade thanks to virtualization. Before Network Virtualization Overlay (NVO), data centers were limited to 4096 broadcast domains which could be problematic for large data centers to support a multi-tenancy architecture. Virtual […]
VMware Tanzu Community Edition now includes advanced software supply chain tooling that helps application teams deliver software more rapidly, securely, and efficiently at scale. The 0.11 release of Tanzu Community Edition, available today, introduces new supply chain choreography capabilities […]
According Release Notes for Cisco UCS Manager, Release 4.2(1l) We have a fix for CSCvz43359 Traffic using GENEVE overlay sometimes leaves wrong VNIC when GENEVE Offload is enabled on VIC14xx:
|Defect ID||Symptom||First Bundle Affected||Resolved in Release|
|CSCvz43359||On a Cisco UCS server using an NSX-T topology, data traffic using a GENEVE overlay sometimes left the wrong vNIC when GENEVE Offload was enabled on a VIC 1400 series Fabric Interconnect. This issue is resolved.||4.2(1d)C||4.2(1l)C|
Traffic using GENEVE overlay sometimes leaves wrong VNIC when GENEVE Offload is enabled on VIC14xx
Symptom: Rapid mac moves observed on Fabric Interconnect and northbound switches where mac address belongs to device using GENEVE overlay. pkcatp-uw in ESXi kernel was not able to observe this phenomenon. This was only observable via tcpdump on the physical VIC adapter in the debug shell.
Conditions: This was specifically seen in an NSX-T topology though more general use of GENEVE offloading in the hardware would likely show same behavior. The NSX-T TEP mac addresses should be ‘bound’ to a physical interface unless there is a topology change. In this circumstance, we observed the TEP macs rapidly moving from Fabric A to Fabric B and vice versa while the teaming/load balancing policy was set to Active/Active in ESXi and NSX. NSX-T uses BFD Control frames between hosts and BFD leverages GENEVE. When GENEVE Offloading is enabled in the VIC adapter policy, this causes some small number of these BFD frames to egress the wrong physical link which causes the unexpected mac move behavior on northbound devices.
Be aware of the issues below found in NSX-t 3.1.3 and 3.1.3.x. If you are considering moving to NSX-T 3.1.3.x, please upgrade directly to 220.127.116.11.1.
This issue is observed when bulk vMotions occur in the NSX-T environment, following are some of the probable scenarios:
- Migration of multiple VMs with each VM comprising of multiple vNICs
- Multiple IP sets configured in CIDR form per rule
- Multiple rules containing same IP Sets
- VMs from a non-upgraded NSX-T host migrated to an upgraded NSX-T host
- Set DRS to manual on the ESXi Cluster and avoid performing bulk vMotions
Fixed in NSX-T 18.104.22.168, but recommended to upgrade directly to 22.214.171.124.1 due to the issue below.
This issue is fixed in NSX-T 126.96.36.199.1. Also, NSX-T 3.2 is not impacted by this.
vExpert 2022 Awards Announcement
Tweet Thank you to everyone who applied for vExpert and to the vExpert PROs for managing the voting process, it’s a lot of work! We are pleased to announce the list of 2022 vExperts. You can visit the vExpert Directory to see the list and profiles of each vExpert. All of the new and returning … Continued The post vExpert 2022 Awards Announcement appeared first on VMware vExpert Blog.