All TKB Articles in VMware NSX

Starting with NSX version 4.1, many more certificates are visible in NSX. Those certificates have always been present on the platform, even in previous versions, but it was impossible to lifecycle them. This document will help the reader understand the purpose of all the certificates part of the NSX platform. It will provide examples covering common certificate-related tasks an NSX administrator may tackle while administering NSX. To make these examples reproducible, they are presented in the form of bash scripts. We opted to use bash for maximum portability. The scripts mainly use curl to perform API calls to the NSX API and use the jq to process the returned JSON data structures. You must install jq on your system to run the sample scripts. You can use your system package manager (i.e., apt or homebrew) The scripts are provided for educational purposes only. You should perform your validations before leveraging them on production systems. The current doc applies to NSX version 4.1.1 and later  Note: copy and paste from the PDF doc will lead to formatting errors. All the scripts are available on GitHub for easy copy and paste: https://github.com/vmware-nsx/nsx_certificates_cookbook Author: NSX Product Team

NSX Operation Playbook 4.1.1 https://communities.vmware.com/t5/VMware-NSX-Documents/NSX-Operation-Playbook/ta-p/2983367   NSX Operation Design Guide 3.2 https://communities.vmware.com/t5/VMware-NSX-Documents/NSX-T-3-2-Operation-Design-Guide/ta-p/2971865   NSX Operation Design Guide 3.0 https://communities.vmware.com/t5/VMware-NSX-Documents/NSX-T-3-0-Operation-Guide/ta-p/2814610  

NSX playbook provides detailed and step by step guide on specific use cases.  The purpose of the playbook  is to serve as a guide for day-to-day NSX operations and to facilitate the learning process for NSX.

We have made significant improvements to NSX Operation from release 3.0 to 3.2. In this version of the Operation Guide, we will only highlight the new capabilities available in the 3.2 release. A holistic version of 3.2 Operation Guide will be published later.

Hallo zusammen, ich suche nach einer Hardware Kompatibilitätsliste für NSX-T inkl. Microsegmentation. Genauer gesagt, ist HPE DL325 Gen10 Plus Server für NSX-T  inkl. Microsegmentation geeignet? Besten Dank im Voraus TBC

VMware NSX Data Center is a full-stack Software-Defined Networking and Security platform from VMware. The full-stack solution (L2/L3 to L4-L7 services ) is flexible and scalable from a minimum footprint of two hosts to the cloud-scale need of large enterprises. This document aims to build a simplified consumption model based on two prescriptive use cases suitable for small footprint, single rack, and satellite data centers. The two use cases offered in this design guide are: A simplified security solution designed for existing workloads where the physical network retains many networking functionalities. A full-stack design that primarily targets new deployments minimizing interaction with the external network while providing extensive flexibility and Network and Security services inside the solution. The solutions presented focus on the following goals and parameters: Physical network-friendly configuration – minimum configuration Leverage existing knowledge base from vSphere and Security Admin Exploit the features and capabilities from NSX-T to build a flexible yet consolidated solution for a variety of application needs, services (NAT, VPN, FW), and security Scope of deployment meeting most common footprint for small workload, satellite DC, and hosted solutions Self-contained guidance and step-by-step design rational This document incorporates two main sections. Each of them addresses the two use cases at a different level. Section 2 covers a high-level overview of the two solutions, together with their value proposition in the context of well-defined requirements and constraints. We also include a brief overview of the relevant NSX-T components. Section 3 provides a detailed design and engineering specification for both use cases. It includes a comprehensive list of assumptions on the supporting infrastructure. Design decisions have accompanying justifications and implications for making the designs actionable and the rationale behind the choices clear and transparent. An example of end-to-end automation for the DC in a Box use case is available here. Please use the branch specific to your version. This version (3.2) of the design guide includes the following updates: Distributed firewall implementation on vCenter distributed port-groups NSX vCenter server plug-in included as part of the simple security for applications use case NSX Application Platform added as an optional component for both use cases to support NSX Intelligence and Advanced Threat Prevention features Next Generation Gateway Firewall added as an optional component in the DC a box design  NSX Advanced Load Balancer added as an optional component in the DC a box design  The Easy Adoption guide for NSX-T version 3.1 is available on this community page Readers are encouraged to send feedback to NSXDesignFeedback_AT_groups_vmware_com (convert to email format).

The NSX Distributed Firewall has added malware detection and prevention support for Linux guest endpoints (VMs). Linux has become the most common operating system across multi-cloud environments. In addition, we expanded the support for malware analysis for known and unknown files. Along with hash-based detection for new files, we added support for local and cloud analysis for unknown files of up to 64MB. Prior to NSX 4.0.1.1, the NSX Gateway supported Active/Standby High Availability mode where traffic is forwarded through a single active NSX Gateway.  This deployment mode required additional design and architecture considerations such as limits induced by the Active/Standby mode on bandwidth and CPU utilization. Additionally, 4.0.1.1 brings added support for malware detection to the NSX Gateway Firewall running directly on bare metal, allowing for consistent protection regardless of whether customers choose a virtual or physical form factor NSX 4.0.1.1 introduces 16 additional NSX Edge metrics that further enhance monitoring and troubleshooting.  This includes flow cache metrics, queue occupancy for fast path interfaces, and NIC throughput on ingress and egress on the NSX Edge fast path interfaces. more details refer - https://blogs.vmware.com/networkvirtualization/2022/11/nsx-4-0-innovations.html/  

Highlights: This updated version of the document aligns with NSX version 3.2. It includes the following updates: NSX vCenter server plug-in for the simple security for applications use case Distributed Firewall on vCenter distributed virtual port-groups for VLAN-only micro-segmentation NSX Application platform as an optional component to support NSX intelligence and Advanced Threat Prevention features for both the simple security for applications and the data center in a box use cases NSX Next-Generation gateway firewall as an optional component for the data center in a box use case NSX Advanced Load Balancer as an optional component for the data center in a box use case About the NSX Easy Adoption Design guide: VMware NSX Data Center is a full-stack Software-Defined Networking and Security platform from VMware. The full-stack solution (L2/L3 to L4-L7 services ) is flexible and scalable from a minimum footprint of two hosts to the cloud-scale need of large enterprises. This document aims to build a simplified consumption model based on two prescriptive use cases suitable for small footprint, single rack, and satellite data centers. The two use cases offered in this design guide are: A simplified security solution designed for existing workloads where the physical network retains many networking functionalities. A full-stack design that primarily targets new deployments minimizing interaction with the external network while providing extensive flexibility and Network and Security services inside the solution. The solutions presented focus on the following goals and parameters: Physical network-friendly configuration – minimum configuration Leverage existing knowledge base from vSphere and Security Admin Exploit the features and capabilities from NSX-T to build a flexible yet consolidated solution for a variety of application needs, services (NAT, VPN, FW, LB), and security Scope of deployment meeting most common footprint for small workload, satellite DC, and hosted solutions Self-contained guidance and step-by-step design rational This document incorporates two main sections. Each of them addresses the two use cases at a different level. Section 2 covers a high-level overview of the two solutions, together with their value proposition in the context of well-defined requirements and constraints. We also include a brief overview of the relevant NSX-T components. Section 3 provides a detailed design and engineering specification for both use cases. It includes a comprehensive list of assumptions on the supporting infrastructure. Design decisions have accompanying justifications and implications for making the designs actionable and the rationale behind the choices clear and transparent. Additional resources and next steps An example of end-to-end automation for the DC in a Box use case is available on github The repository has different branches for different NSX versions. Readers are encouraged to reference the NSX Reference Design Guide for NSX implementations outside of the scope of the NSX Easy Adoption Design Guide. Readers are encouraged to send feedback to NSXDesignFeedback_AT_groups_vmware_com (convert to email format).

This document has been created by VMware NSX Advanced Load Balancer (Avi) Field Engineering to facilitate migrations from legacy load balancing appliances such as the F5 Local Traffic Manager (LTM) to the software defined NSX Advanced Load Balancer (Avi) platform.

Question Hi everybody, I want to provide to application responsibles an easy way to manage their Virtual Servers. I have spent few hours to try virtualservice model of ALB macro API method but this latter is not well documented. Until now, I have only configured successfully virtual servers and all its related components in the default cloud in the admin tenant. Unfortunately, it is not my use case and I still receive the response below as soon I try to specify another cloud. { "error": "Error in creating VirtualService test1_vs: Error in creating VirtualService test1_vs: tier1_lr not configured" } I use AVI 21.1.4 version and here is the body I use. { "model_name": "VirtualService", "data": { "name": "test1_vs", "vrf_context_ref":"/api/vrfcontext?name=sirveglabnsxt1t11", "tenant_ref": "/api/tenant?name=admin", "cloud_ref": "/api/cloud?name=POD_lab_alw", "se_group_ref": "/api/serviceenginegroup?name=lab_alw_seg1", "tier1_lr": "/infra/tier-1s/sirveglabnsxt1t11", "services": [ { "port": 80 } ], "vsvip_ref_data": { "name": "test1_vsvip", "vip": [ { "ip_address": { "type": "V4", "addr": "10.253.222.162" }, "cloud_ref": "/api/cloud?name=POD_lab_alw", "vrf_context_ref":"/api/vrfcontext?name=sirveglabnsxt1t11", "tier1_lr": "/infra/tier-1s/sirveglabnsxt1t11" } ] }, "application_profile_ref": "/api/applicationprofile?name=http_application_profile", "pool_ref_data": { "name": "test1_pool", "cloud_ref": "/api/cloud?name=POD_lab_alw", "tier1_lr": "/infra/tier-1s/sirveglabnsxt1t11", "servers": [ { "ip": { "type": "V4", "addr": "10.253.221.45" } }, { "ip": { "type": "V4", "addr": "10.253.221.46" } } ], "health_monitor_ref": "/api/healthmonitor?name=monitor_http_standard" } } } Thank in advance for any help.     Answer  

Workloads come in various forms factors like virtual machines, containers, and physical servers. In addition, workloads are hosted in different environments like on-premises, native cloud, or managed cloud. The heterogeneity of the workload form factor and deployment type further challenges the organizations regarding security coverage, policy consistency, number of platforms to be managed, and overall operational simplicity. The requirement of an organization is to have an operationally simple platform that provides consistent policy across virtual machines, containers, physical servers, and native cloud workloads without compromising the application and data security. NSX Intelligence, a security analytics and policy management solution, automatically determines the communication patterns across all types of workloads, makes security policy recommendations based on those patterns, and checks that traffic flows to conform to the deployed policies.

Two NSX Anti-Malware Presentations: 101 level for a quick NSX Malware Detection and Prevention presentation what's new in NSX 4.0.1.1 what it is how it works and its reporting capabilities 301 level for deeper NSX Malware Detection and Prevention presentation with the same points as 101, plus packet walk of Gateway and Distributed Malware Detection and Prevention reporting requirements / limitations / scale high-availability malware file DB population installation upgrade troubleshooting   NSX Malware Detection and Prevention demo is also available here.    Note: Those ToI may be updated in the future so always check you have the latest version. 101 ToI version is 1.1 (for NSX 4.1) done on 09/19/2023. 301 ToI version is 1.4 (for NSX 4.1) done on 11/07/2023. Older NSX-T releases are also attached if needed.  

Two NSX Physical Server Presentations: 101 level for a quick NSX Physical Server presentation topologies with Physical Servers NSX services supported with Physical Servers 301 level for deeper NSXPhysical Server presentation with the same points as 101, plus detailed supported topologies preparation and installation troubleshooting   Note: This document may be updated in the future so always check you have the latest version. NSX-T 4.0-4.1: The latest physical server 101 ToI version for NSX 4.0-4.1 release is 1.0 done on 03/15/2023 The latest physical server 301 ToI version for NSX 4.0-4.1 release is 1.5 done on 10/30/2023. Updated version 1.1 03/08/2023 = Updated deck with NSX 4.1 enhancement (support on all Linux of topology VLAN bond mode 1 with bond configured in Linux). Updated version 1.3 04/14/2023 = update on licenses (NSXROBO licenses doesn't support Physical Server). Updated version 1.4 08/18/2023 = update on NSX Intelligence support and no SE Linux support. Updated version 1.5 10/10/2023 = update on 4?1?2 new topology supported NSX-T 3.2: The latest physical server encyclopedia version for NSX-T 3.2 release is 1.6 done on 04/14/2023. Updated version 1.1 04/11/2022 = clarification of DFW services supported slide 10. Updated version 1.2 05/25/2022 = clarification of the different topologies supported. Updated version 1.3 06/10/2022 = clarification/correction of the different topologies supported. Updated version 1.5 12/08/2022 = update on pNICs support. Now all pNICs are supported (in case of Overlay on Windows, the pNIC driver must support jumbo packets though). Updated version 1.6 04/14/2023 = update on licenses (NSX ROBO licenses doesn't support Physical Server). Updated version 1.7 08/18/2023 = update on NSX Intelligence support and SELinux not supported.

This is the VMware® NSX-T 3.2 Security Configuration Guide.This guide provides prescriptive guidance for customers on how to deploy and operate VMware® NSX-T in a secure manner. Guide is provided in an easy to consume spreadsheet format, with rich metadata (i.e. similar to existing NSX for vSphere & VMware vSphere Security Configuration Guides) to allow for guideline classification and risk assessment. Feedback and Comments to the Authors and the NSX Solution Team can be posted as comments to this community Post (Note: users must login on vmware communities before posting a comment). Other related NSX Security Guide can be found @ https://communities.vmware.com/docs/DOC-37726 --The VMware NSX PM/TPM Team

This document highlights NSX-T Service Interfaces capabilities including:   . All use cases currently supported / not supported   . Configuration steps   . Failover   . Troubleshooting   . Packet Capture   Document Version: 2.1 (Updated November 2021)  

When completing an upgrade precheck in SDDC-Manager the NSX-T password validity check fails:   Impact - HIgh: Password has expired and upgrade will fail due to this.  You will see the following in the /var/log/vmware/vcf/lcm/lcm-debug.log:   2021-06-17T19:10:20.089+0000 DEBUG [vcf_lcm,0000000000000000,0000,precheckId=af8ce3f0-615b-4387-919c-f123e797d4a5,resourceType=NSX_T,resourceId=nsx.corp.local] [c.v.e.s.l.p.c.u.VmwPrimitiveUtils,pool-3-thread-48] Password validation status for API credential type of resource: nsx.corp.local is VALID 2021-06-17T19:10:20.090+0000 DEBUG [vcf_lcm,0000000000000000,0000,precheckId=af8ce3f0-615b-4387-919c-f123e797d4a5,resourceType=NSX_T,resourceId=nsx.corp.local] [c.v.e.s.l.p.util.PrimitiveHelper,pool-3-thread-48] Password validation for API credential type of resource: nsx.corp.local is VALID 2021-06-17T19:10:20.090+0000 DEBUG [vcf_lcm,0000000000000000,0000,precheckId=af8ce3f0-615b-4387-919c-f123e797d4a5,resourceType=NSX_T,resourceId=nsx.corp.local] [c.v.e.s.l.p.c.u.VmwPrimitiveUtils,pool-3-thread-48] Password validationexpiry data for API credential type of resource: nsx.corp.local is SUCCEEDED 2021-06-17T19:10:20.090+0000 DEBUG [vcf_lcm,0000000000000000,0000,precheckId=af8ce3f0-615b-4387-919c-f123e797d4a5,resourceType=NSX_T,resourceId=nsx.corp.local] [c.v.e.s.l.p.c.u.VmwPrimitiveUtils,pool-3-thread-48] Password validationexpiry for API credential type of resource: nsx.corp.local is in -22 days 2021-06-17T19:10:20.090+0000 INFO  [vcf_lcm,0000000000000000,0000,precheckId=af8ce3f0-615b-4387-919c-f123e797d4a5,resourceType=NSX_T,resourceId=nsx.corp.local] [c.v.e.s.l.p.i.nsxt.NsxtPrimitiveImpl,pool-3-thread-48] Completed precheck task NSX_T_PASSWORD_VALIDITY_CHECK  on resource id nsx.corp.local  with status RED   Note: This precheck will also fail if the password expiry is cleared using the command "clear user admin password-expiration". It is a known issue, please refer the KB SDDC manager falsely shows the password for NSXT component as expired for more information.      Cause NSX-T does not support setting password expiry for root or admin to 99999 NSX-T password expiry can be set to a maximum period of 9999      Resolution Set password expiry for root and admin to 9999: 1. SSH to NSX-T VIP with admin credentials 2. Check password expiry for both root and admin accounts get user admin password-expiration 3. If the password has expired or is set to 99999 use the following command to set password expiry to 9999 set user admin password-expiration 9999 4. Retry upgrade precheck in SDDC-Manager

We are pleased to announce the introduction of VMware NSX Advanced Firewall for VMware Cloud on AWS, which takes the network security capabilities of VMware Cloud on AWS SDDC to a new level. Adding NSX Advanced Firewall features allows organizations to define security policies at Layer 7 while enabling deep packet inspection across all vNICS within the software-defined data center (SDDC).      NSX Advanced Firewall capabilities help you secure your applications against a never-expanding set of threats on the internet. Specifically, it includes a robust set of networking and security capabilities that enable customers to run production applications in the cloud.  This capability allows you to:  Detect attempts at exploiting vulnerabilities in your workloads.  Gain protection against vulnerabilities inside your SDDC with granular application-level security policies.  Reduce the attack surface of your workloads by allowing only the intended application traffic to run in your SDDC.  Seamlessly provide inspection for all traffic without a single inspection bottleneck.  Achieve your compliance goals.  Customers can purchase the NSX Advanced Firewall as an add-on in VMware Cloud on AWS.