• VCF Fleet with Fault Domains and Disaster Recovery Design

    This article is contunuation of the previouse one: VCF Fleet with Disaster Recovery (Across Regions)

    Finally, we bring these concepts together into a combined design that uses both fault domains and disaster recovery.

    Here we:

    • Use availability zones and stretched clusters within a region to provide site high availability and continuous availability.

    • At the same time, we replicate to another region to provide disaster recovery.

    VCF Fleet with Fault Domains and Disaster Recovery Design

  • VCF Fleet with Disaster Recovery (Across Regions)

    This article is contunuation of the previouse one: VCF Fleet with Site High Availability (Across Zones)

    Now let’s move from high availability within a region to disaster recovery across regions.

    On this slide we have:

    • Region 1, which acts as the primary site, and

    • Region 2, which acts as the disaster recovery site.

    VCF Fleet with Disaster Recovery Across Regions

  • VCF Fleet with Site High Availability (Across Zones)

    This article is contunuation of the previouse one: VCF Fleet Basic with Multiple VCF Instances

    Next, let’s move from basic fleet management to site‑level high availability within a region.

    This design uses what you may already know as a stretched cluster:

    • We have a single VCF instance spanning two availability zones.

    • Compute and storage are stretched between the zones, giving us continuous availability and IP portability across them.

    VCF Fleet with Site High Availability Across Zones

  • VCF Fleet Basic with Multiple VCF Instances

    This article is contunuation of the previouse one: VCF Fleet Basic

    Once you’ve deployed that basic VCF instance with Ops and Automation, you can scale out to multiple VCF instances.

    On the icture below you can see several VCF instances, each with:

    • Its own workload domain components – vCenter, NSX, and storage.

    • Its own management domain where required.

    VCF Fleet Basic with Multiple VCF Instances

  • VCF Fleet Basic

    This is first of 5 Fleet design patterns.

    This is core concept of a VCF Fleet Basic deployment.

    Think of this as our baseline VCF instance design – the foundation for all the other VCF Fleet deployment options I’ll cover next.

     VCF Fleet Basic

  • VMware released video for upgrade from vSphere 8.x with LCM to the VCF 9.0

    VMware has released a new video demonstrating the end-to-end upgrade journey from an existing vSphere 8.x environment with Aria Suite to the latest VMware Cloud Foundation (VCF) 9.0 platform.

    LINK TO VIDEO

    The walkthrough showcases an environment that initially relies on Aria Suite Lifecycle Manager and Aria Operations, and illustrates how it is transitioned to the new VCF 9 operating model.
    The process begins with upgrading Aria Lifecycle Manager to version 8.18 Patch 2 or later, which is a mandatory prerequisite. Using this updated lifecycle manager, Aria Operations is then upgraded to VCF Operations 9.0, during which a new component—the VCF 9 Fleet Management Appliance—is automatically deployed.

  • Fault Domains - Availability Zones and Regions

    Standardizing Terminology Across Cloud and VCF

    The key idea is to avoid inventing proprietary terminology and instead rely on concepts that are already widely understood across the cloud industry. Terms such as Region and Availability Zone are common reference points across AWS, Google Cloud, Azure, and other platforms—and they translate well into VMware Cloud Foundation (VCF) architectures.

    By using familiar terminology, we make architecture discussions clearer, more portable, and easier to align with existing cloud operating models.

    Fault Domains

  • VCF 9: Operational Transformation and Platform Convergence

    When we look at VMware Cloud Foundation (VCF) operations today, it’s clear that there have been significant and deliberate changes aimed at simplifying operations while expanding platform capabilities.

    1. Major Improvements in Operations and Troubleshooting

    VCF now delivers a much more streamlined operational and troubleshooting experience, primarily through a centralized management console. Key operational areas have been significantly enhanced:

    • Centralized management console that reduces tool sprawl

    • Improved password and credential management

    • Dramatically enhanced lifecycle management (LCM), including support for VMware ESXi Live Patch, which minimizes downtime and operational risk

    • Centralized license management, addressing challenges introduced by the new Broadcom operating and subscription model

    While some elements—such as registration workflows and licensing portals—are still in their early iterations and continue to evolve, each release brings improved stability, usability, and billing transparency.

    VCF Operations

     

  • VMware Cloud Foundation Architecture poster

    The VMware Cloud Foundation Architecture poster has been comprehensively refreshed to reflect the major innovations introduced with VCF 9, marking a significant evolution of the platform. It delivers a powerful visual narrative that brings the full software-defined data center and cloud operating model to life.

    vmware cloud foundation architecture poster v01 

    Download full version

    More than a diagram, the poster acts as a strategic blueprint for understanding how VCF enables and operates modern private cloud environments. It clearly demonstrates how the platform supports traditional virtual machines alongside cloud-native and next-generation workloads, including Kubernetes, AI, and big data, across multiple data centers and edge locations.

    At its core, the poster showcases how compute, storage, networking, and security are tightly integrated into a single, automated, and lifecycle-managed stack. It illustrates how VCF is deployed, scaled, and operated as a true end-to-end private cloud platform, delivering cloud-like agility with enterprise-grade control.

  • NSX Edge Design in VMware Cloud Foundation

    Why Dedicated vSphere Clusters for NSX Edge VMs Matter

    Executive Summary

    In VMware Cloud Foundation (VCF), NSX Edge Virtual Machines (VMs) play a critical role in delivering north–south and east–west networking services such as Tier-0/Tier-1 routing, NAT, load balancing, and VPN. Because NSX Edge VMs are performance-sensitive and foundational to overall platform availability, their placement and host design are crucial architectural decisions.

    This article is attmpt to explain why dedicated vSphere clusters for NSX Edge VMs are a best practice in VCF, and why collapsing Edge and compute workloads into shared clusters does not provide real cost savings and often introduces operational and availability risks.

    The Cost Myth: Shared Edge and Compute Does Not Reduce Resource Consumption

    A common misconception is that placing NSX Edge VMs on shared compute clusters reduces infrastructure cost by avoiding dedicated hosts. In reality, this approach does not reduce overall CPU or memory consumption.

    Key considerations include:

    • NSX Edge VMs require a fixed amount of CPU and memory to deliver predictable performance. Whether they run on shared or dedicated hosts, the resource demand remains unchanged.

    • Achieving equivalent Edge performance on shared, non-tuned ESXi hosts often requires:

      • Deploying more NSX Edge VMs

      • Spreading them across a larger number of ESXi hosts

      • Limiting placement to no more than one Edge VM per ESXi host to avoid contention

    These requirements quickly negate any perceived cost benefit of collapsing Edge and compute workloads.

    Additionally, performance tuning applied to optimize NSX Edge VMs—such as CPU pinning or enhanced datapath configurations—can negatively impact general-purpose workloads and reduce the achievable consolidation ratio of the cluster.

    Simplification Through Dedicated Edge Clusters

    Deploying dedicated ESXi hosts and clusters for NSX Edge VMs significantly simplifies the ESXi configuration and operational model.

    Benefits include:

    • Tailored host configuration specifically optimized for NSX Edge workloads

    • Ability to adopt the recommended 4-pNIC design, ensuring proper traffic separation and redundancy

    • Enablement of Enhanced Datapath (EDP – interrupt mode) on a controlled subset of hosts without impacting application workloads

    • Reduced configuration complexity compared to maintaining mixed host profiles in a shared cluster

    In contrast, shared environments require compromises that often prevent full adoption of NSX best-practice configurations.

    Improved Performance Troubleshooting and Operational Clarity

    Troubleshooting network performance issues is inherently more complex when NSX Edge VMs share clusters with dynamic application workloads.

    Challenges in shared clusters include:

    • Frequent NSX Edge VM movement due to DRS rebalancing

    • Difficulty correlating performance issues to specific host-level contention

    • Reduced visibility when Edge and compute workloads compete for the same resources

    Dedicated Edge clusters provide:

    • Stable VM placement, simplifying root cause analysis

    • Predictable performance baselines

    • Clear operational boundaries between networking infrastructure and application workloads

    Reduced vMotion Dependency and Improved Availability

    NSX Edge VMs are highly sensitive to vMotion events. Each vMotion operation can temporarily affect packet processing and, by extension, the availability of many dependent workloads.

    With dedicated Edge clusters:

    • NSX Edge VM vMotion is minimized and typically occurs only during planned ESXi maintenance

    • DRS does not need to frequently rebalance Edge VMs due to unrelated workload churn

    • The blast radius of any maintenance activity is reduced and more predictable

    In shared clusters, frequent workload changes often trigger DRS-initiated vMotion events for NSX Edge VMs, increasing the risk of service disruption.

    Additional Optimization Opportunities

    Because NSX Edge VMs have minimal or no dependency on storage services such as vSAN and rarely require vMotion:

    • Network I/O Control (NIOC) can be disabled as a performance-tuning option

    • Host configurations can be streamlined specifically for packet processing efficiency

    • Operational policies can be optimized for infrastructure services rather than application agility

    These optimizations are difficult—or unsafe—to apply in shared clusters hosting diverse workloads.

    Conclusion

    In VMware Cloud Foundation, NSX Edge VMs are infrastructure services, not general-purpose workloads. Treating them as such by deploying dedicated vSphere clusters delivers:

    • No increase in total infrastructure cost

    • Simpler and cleaner ESXi host configurations

    • Improved performance consistency

    • Easier troubleshooting

    • Reduced operational risk and improved availability

    For these reasons, VMware recommends dedicated NSX Edge clusters as the preferred and most robust design for production VCF environments.

  • VCF Architecture - Multi Availability Zone (AZ) Deployment using stretched Clusters

    Modern enterprise workloads demand high availability, resilience, and automated recovery across geographically separated locations. VMware Cloud Foundation (VCF) addresses these requirements through Multi Availability Zone (AZ) deployments using vSphere and vSAN stretched clusters. This architecture enables continuous service availability even during an entire Availability Zone outage, while maintaining centralized management and operational simplicity.

     Multi AZ

    What Is a Stretched Cluster in VCF?

    A vSphere stretched cluster is a single vSphere cluster with vSAN storage that spans multiple Availability Zones (AZs). Each AZ is treated as an independent Failure Domain, typically representing a separate data center, building, or fault-isolated zone with independent power, cooling, and network paths.

    In a stretched cluster architecture:

    • Compute hosts are distributed across two AZs.

    • vSAN synchronously replicates data between AZs.

    • A vSAN witness node provides quorum to prevent split-brain scenarios.

    This design allows workloads to remain available and consistent even if one AZ becomes unavailable.

    Key Architectural Components

    1. Availability Zones as Failure Domains

    Each Availability Zone acts as a vSAN Fault Domain, ensuring that data replicas are placed across AZs. This guarantees that the loss of an entire AZ does not impact data availability or integrity.

    2. vSAN Stretched Storage

    vSAN uses synchronous replication between AZs to maintain identical data copies. This ensures:

    • Zero data loss (RPO = 0)

    • Transparent storage access for virtual machines

    • Consistent performance under normal operating conditions

    3. vSAN Witness Node

    A vSAN witness node is mandatory for stretched clusters. It:

    • Maintains quorum during failures

    • Resides in a third fault location (separate from both AZs)

    • Stores only metadata, not workload data

    The witness ensures deterministic behavior during AZ failures and enables automated recovery.

    High Availability and Automated Recovery

    One of the major benefits of stretched clusters in VCF is the retention of native vSphere features:

    • vSphere HA automatically restarts affected virtual machines in the surviving AZ in the event of an AZ failure.

    • DRS (Distributed Resource Scheduler) continues to balance workloads dynamically based on available compute resources.

    • No manual intervention is required for workload recovery, significantly reducing operational risk and recovery time.

    This results in a fully automated and highly resilient platform capable of surviving complete AZ outages.

    Deployment Order and Best Practices in VCF

    Management Domain First

    In VCF, the Management Domain cluster must be stretched first before stretching any VI Workload Domain (WLD) vSAN clusters. This is critical because:

    • The Management Domain hosts core infrastructure services such as SDDC Manager, vCenter, NSX, and lifecycle management components.

    • Ensuring its availability is foundational for the entire VCF stack.

    Stretch VI Workload Domains as Needed

    After the Management Domain is successfully stretched:

    • Additional vSAN-based VI Workload Domain clusters can be stretched selectively.

    • Not all clusters need to be stretched—only those hosting workloads with strict availability and resiliency requirements.

    • This approach allows organizations to balance cost, complexity, and availability.

    Use Cases and Benefits

    Multi-AZ stretched clusters in VCF are ideal for:

    • Mission-critical applications requiring continuous availability

    • Environments with zero or near-zero downtime requirements

    • Enterprises seeking simplified disaster avoidance rather than traditional disaster recovery

    Key benefits include:

    • Protection against entire AZ failures

    • Zero data loss and rapid recovery

    • Fully automated operations using native vSphere capabilities

    • Consistent management through VMware Cloud Foundation

    Conclusion

    VCF Multi Availability Zone deployments using stretched clusters provide a powerful, resilient architecture for modern private cloud environments. By leveraging vSphere HA, DRS, and vSAN stretched storage—with the correct deployment order starting from the Management Domain—organizations can achieve enterprise-grade availability with minimal operational overhead.

    This architecture transforms Availability Zones into active-active infrastructure components, ensuring business continuity even in the face of major infrastructure failures.

     
     
     
     
     
     

  • VCF Architecture - Multi VCF - NSX Federation

    In VMware Cloud Foundation (VCF), organizations often need to deploy multiple VCF instances across different geographical regions or data centers for reasons like disaster recovery, business continuity, scalability, and regional optimization. To address these needs, NSX Federation allows for a seamless, consistent networking and security policy management across multiple VCF instances deployed in different sites. This multi-VCF instance deployment with NSX Federation creates a unified, scalable network architecture across a distributed cloud environment.

  • VCF Architecture - Single Site - Dedicated NSX Domains

    In VMware Cloud Foundation (VCF), the Standard Architecture provides a flexible and scalable design for deploying cloud infrastructure in an enterprise environment. When using dedicated NSX domains for each Workload Domain (WLD), the architecture is optimized for scenarios where you need isolated, independent network and security configurations for each workload domain, enhancing security, performance, and scalability.

  • VCF Architecture - Single Site - Single NSX Domain

    Standard Architecture is designed for more flexible and scalable deployments than the Consolidated Architecture. A key feature of the VCF Standard Architecture is the single NSX domain for all VI Workload Domains (WLDs), which provides a unified networking and security model across the entire deployment, even when multiple WLDs are involved. This architecture is particularly suitable for medium to large environments that require scalability, multi-tenant support, and centralized networking and security management.

  • VCF Architecture - Single Site - Consolidated

    The Consolidated Architecture for VCF is designed for smaller or simpler deployment scenarios, where a single data center or site is sufficient to handle the infrastructure needs of an enterprise. In this model, all core VCF components are deployed on the same physical infrastructure, including vSphere, vSAN, NSX, and vCenter. This deployment pattern simplifies the overall architecture by reducing the complexity of managing multiple sites or data centers, making it ideal for smaller organizations or pilot environments.

  • Enhanced Data Path - High Performance Switch

    This is part of VMware's platform for managing and integrating virtualization, compute, storage, and networking in a hyper-converged infrastructure (HCI) environment.

    Let’s break down what the Enhanced Data Path and the High-Performance Switch mean within the context of VCF:

    Enhanced Data Path

    • The Enhanced Data Path is a feature aimed at improving networking performance and optimizing data flow within a virtualized data center. It focuses on making network communication more efficient, reducing latency, and ensuring that data moves through the system at high speed with minimal overhead.

    • In virtualized environments, traditional networking may introduce delays due to virtual switches and network overlays that handle the routing of traffic. The Enhanced Data Path helps streamline this process, particularly for workloads requiring high throughput, such as data-intensive applications, machine learning, or real-time processing.

    • The Enhanced Data Path likely involves techniques like:

      • Direct data forwarding to reduce the need for virtual switch intervention, bypassing some software layers for faster throughput.
      • Optimized traffic flow management, especially for east-west traffic (VM-to-VM or storage-to-VM) inside the data center.
      • Improved tunneling and encapsulation in network overlays (e.g., VXLAN), ensuring that network packets are processed more efficiently.

    High-Performance Switch

    • The High-Performance Switch is SDN features in VMware NSX that are designed to enable high-throughput, low-latency, and scalable networking. These switches are designed to handle large-scale deployments and are optimized to work in virtualized environments.

    • High-Performance Switch include:

      • Improved packet processing capabilities that are optimized for modern data center traffic patterns.
      • Efficient data plane processing, often leveraging hardware acceleration where available (such as DPDK (Data Plane Development Kit) or SR-IOV for reducing virtualization overhead).
      • Support for traffic segmentation and QoS (Quality of Service) to prioritize critical workloads over less important traffic, ensuring predictable performance.
      • Enhanced Security: Security features like micro-segmentation and flow monitoring are integrated into these high-performance switches to protect the network without compromising performance.

    enhanced traffic

    How to enable:

    To Enable during cluster addition via SDDC Manager (this feature is not enableds by default):

    1. Under Switch Configuration
    2. Select "Enhanced Datapath Interrupt"

    It will be enables on all nodes of the cluster

    Confirm which mode is in use:

    •  Check the corresponding transport node profile in NSX Manager

    How to enable using API:

    POST: https:///v1/clusters
"name": "<vds-name>",
"'nsxtSwitchConfig" : ( 
"hostSwitchOperationalMode": "ENS-Interrupt"

  • Overview: NSX in VMware Cloud Foundation 5.2

    VMware Cloud Foundation (VCF) 5.2 is a comprehensive platform that integrates VMware’s compute, storage, networking, and management layers into a single, unified infrastructure. The latest version of NSX in VCF 5.2 introduces several new features and enhancements aimed at improving performance, scalability, network optimization, and manageability. Here’s a detailed look at some of the key enhancements in NSX within VCF 5.2.
    Lets talk briefly about main fetures and in the next few articles I will spend a bit of time focusing on: 
    - TEP Group - Multi-pathing for TEP (Tunnel Endpoints) and
    - Enhanced Data Path - High Performance Switch

    1. Network Assessment and Optimization Report

    VCF 5.2 introduces an enhanced Network Assessment and Optimization Report to provide better visibility into the health and performance of the network infrastructure. This report helps network administrators identify bottlenecks, misconfigurations, or performance issues across NSX networks. The optimization tool analyzes the network's configuration and offers actionable insights and recommendations to improve performance, stability, and security.

    Key benefits:

    • Improved troubleshooting capabilities.
    • Actionable insights for optimizing network designs.
    • Enhanced ability to proactively manage network infrastructure.

    2. Centralized License Management

    It allows administrators to manage NSX licenses across the entire VMware Cloud Foundation stack from a single location. This centralization simplifies license tracking, renewal, and compliance, reducing the complexity of managing separate licenses for different NSX components (such as NSX Manager, NSX Edge, and NSX Distributed Firewall).

    Key features:

    • Centralized dashboard for viewing license status.
    • Automated license assignment across multiple components.
    • Simplified license renewals and upgrades.

    3. Enhanced Image Customization IPv6 Support for NSX Manager

    IPv6 support enables use of IPv6 addressing for both management and operational purposes within NSX components. With this enhancement, organizations can now deploy NSX across IPv6-enabled environments, improving the flexibility of network configurations.

    Key highlights:

    • Full IPv6 support for NSX Manager, ensuring future-proofing in IPv6 networks.
    • Seamless integration with other VMware Cloud Foundation components like vSphere, vSAN, and vCenter.
    • Simplified network management for IPv6-native environments.

    4. BGP Troubleshooting and Monitoring

    NSX in VCF 5.2 brings significant improvements to BGP Troubleshooting and Monitoring. BGP is critical for dynamic routing in large-scale, multi-site networks. Enhanced troubleshooting tools within NSX now allow administrators better diagnose BGP session issues, route advertisements and network path problems.

    Key enhancements:

    • Enhanced visibility into BGP sessions, including real-time status and history.
    • Detailed metrics for route advertisements, session states, and error logs.
    • Streamlined troubleshooting with actionable insights directly within NSX Manager.

    5. Multitenant VPN

    This feature allowing for more robust and scalable VPN solutions. This feature provides secure and isolated connectivity between multiple tenants across various environments, making it ideal for Service Providers or multi-tenant environments.

    Key features:

    • Support for both IPsec and SSL VPN for tenants.
    • Better isolation between tenant networks for security and compliance.
    • Simplified configuration and management of tenant-specific VPNs from a central NSX Manager interface.

    6. Certificate Management Simplification

    Addresses the complexity associated with managing SSL/TLS certificates within NSX. VCF 5.2 simplifies certificate provisioning, renewal, and validation processes, improving both security and operational efficiency.

    Key improvements:

    • Centralized management of certificates across the entire NSX stack.
    • Simplified process for importing, validating, and renewing certificates.
    • Automated certificate expiration alerts and management tasks.

    7. TEP Group - Multi-pathing for TEP (Tunnel Endpoints)

    The TEP Group feature in NSX 5.2 introduces multi-pathing for Tunnel Endpoints (TEPs), enhancing network performance and resiliency. This improvement allows NSX components to use multiple paths for traffic flow between Tunnel Endpoints, helping to avoid network congestion and improve fault tolerance.

    Key benefits:

    • Increased fault tolerance and network availability with multiple paths.
    • Better utilization of network bandwidth across TEPs.
    • Enhanced load balancing between different TEPs, ensuring higher network throughput.

    8. Enhanced Data Path - High Performance Switch

    VCF 5.2 introduces an Enhanced Data Path that includes a High Performance Switch (HPS). The HPS is designed to accelerate data path performance within NSX, improving network throughput, reducing latency, and enhancing overall performance for demanding workloads.

    Key features:

    • Optimized for high-performance networking tasks like vMotion, storage traffic, and East-West traffic within the NSX overlay network.
    • Significant performance improvements for resource-intensive applications and services.
    • Reduced latency and jitter in virtualized environments, making NSX an even better solution for real-time workloads and high-performance computing environments.

    to summarise:

    VCF 5.2, with its advanced NSX features, offers enhanced network optimization, security, and scalability. With improvements in BGP monitoring, IPv6 support, certificate management, and multitenant VPN, it enables businesses to meet the growing demands of their networks while ensuring seamless, high-performance operations. These new features help enterprises streamline their cloud operations, improve performance, and simplify network management in increasingly complex, hybrid environments.

    Check next several related articles...

  • VCF Architecture - 5 classic patterns

    There are four classic patterns in VMware Cloud Foundation (VCF) architecture.

    The main goal of the VCF architecture is to separate the management cluster from the workload cluster by placing them on two distinct uplinks. This design ensures that as your workload increases in density and scale, you don't have to contend with both management and production traffic on the same network path. By keeping these clusters separate, you can easily manage and expand your environment. In the event of an expansion, it's much simpler to evacuate hosts and maintain only the management domain on those hosts, reducing the risk of impact on production workloads.

  • Renewing NSX-T Local certificates - REV

     

    How to Renew NSX-T Local Certificates

    In NSX-T, certificates are crucial for ensuring secure communication between different NSX components (e.g., NSX Manager, NSX Controllers, Edge appliances, etc.). Over time, certificates may expire and need to be renewed to maintain secure communication within the NSX-T environment. Renewing the NSX-T local certificates is an essential task to ensure continued security and proper operation of the system.

    This guide outlines the steps to renew NSX-T local certificates, focusing on the most common process for renewing the internal certificates used by NSX Manager, NSX Edge, and NSX Controllers.

    Prerequisites

    Before renewing NSX-T local certificates, ensure that you meet the following requirements:

    1. NSX-T Manager and Components: The process applies to NSX Manager, NSX Edge, and NSX Controllers.
    2. Backup: Always take a backup of your NSX-T configuration and certificates before proceeding.
    3. Access: Ensure you have administrative privileges to access the NSX Manager CLI or the NSX Manager Web UI.
    4. SSL Certificate Understanding: Familiarize yourself with self-signed certificates or CA-signed certificatesbased on your organization’s certificate management policies.

    Steps to Renew NSX-T Local Certificates

    Option 1: Using the NSX Manager Web Interface

    1. Login to NSX Manager Web Interface:

      • Access the NSX Manager web interface by navigating to the URL: https://<NSX-Manager-IP>
      • Log in using your admin credentials.

    2. Navigate to the Certificates Section:

      • From the NSX Manager Dashboard, go to System > Certificates.
      • You will see the list of certificates in use (including certificates for NSX Manager, NSX Controllers, NSX Edge, etc.).

    3. Renew the Certificates:

      • To renew a certificate, select the relevant certificate from the list (typically the NSX Manager certificate or any other local certificate you need to renew).
      • Click on Renew. You will typically be presented with options to renew using either a CA-signed certificateor self-signed certificate.
        • Self-Signed Certificate: If you are renewing with a self-signed certificate, the system will generate a new certificate for you. Simply click Renew and confirm the operation.
        • CA-Signed Certificate: If you want to use a CA-signed certificate, you'll need to generate a CSR (Certificate Signing Request) and submit it to your Certificate Authority (CA) for signing. Once you receive the signed certificate, upload it into NSX-T.

    4. Apply and Reboot if Necessary:

      • After renewing or uploading the new certificate, apply the changes.
      • Some NSX components (like NSX Manager and NSX Edge) may need to be restarted for the new certificate to take effect.
      • You may also need to redeploy the NSX Edge appliances for the changes to propagate.

    Option 2: Renewing Certificates Using the NSX Manager CLI

    1. Log in to NSX Manager via SSH:

      • Log in to your NSX Manager via SSH as the admin user.
      • Use an SSH client to access the system:
        ssh admin@<NSX-Manager-IP>

    2. Check Existing Certificates:

      • You can view the current certificate details by running the following command:
        arduino
        get certificate
      • This command will list all the certificates in use, including expiry dates.

    3. Generate a New CSR (If Using a CA-Signed Certificate):

      • If you want to renew the certificate using a CA-signed certificate, you need to generate a CSR. This is typically done using the following command:
        php
        certificate csr <certificate-name>
        • Replace <certificate-name> with the specific certificate you want to renew (e.g., NSX-Manager).
        • The system will generate a CSR file and private key for submission to a Certificate Authority (CA).

    4. Upload the Signed Certificate (If Using a CA-Signed Certificate):

      • After receiving the signed certificate from the CA, you will need to upload it to NSX-T. Use the following CLI command:
        certificate import <certificate-name> <path-to-signed-cert-file>
      • Replace <certificate-name> with the specific certificate you are renewing and <path-to-signed-cert-file> with the file path to the signed certificate you received.

    5. Renew Using Self-Signed Certificate:

      • If you are using a self-signed certificate, you can directly renew it with the following command:
        certificate renew <certificate-name>
      • Replace <certificate-name> with the name of the certificate you wish to renew (e.g., NSX-Manager, NSX-Edge, etc.).

    6. Verify the New Certificate:

      • After renewal, verify that the new certificate is applied by running the command:
        get certificate

    7. Restart NSX-T Components (If Required):

      • After renewing the certificates, you may need to restart the relevant NSX components (NSX Manager, NSX Edge, NSX Controllers) for the changes to take effect:
        • To restart NSX Manager, use:
          system restart nsx-manager
        • To restart NSX Edge, use:
          system restart nsx-edge

    Option 3: Renewing Certificates Using the NSX-T API

    For more advanced automation or bulk renewal scenarios, you can use the NSX-T REST API to interact with certificates programmatically.

    1. Authenticate with the NSX Manager API:

      • Use an API client like Postman or curl to authenticate with the NSX Manager API:
        curl -u admin:<password> -k https://<NSX-Manager-IP>/api/v1

    2. Generate a CSR (Certificate Signing Request):

      • To generate a CSR, make a POST request to the /api/v1/certificates/csr endpoint.

    3. Upload the Signed Certificate:

      • Once you have the signed certificate from the CA, upload it using the /api/v1/certificates/importendpoint.

    4. Verify the Certificate Renewal:

      • You can retrieve the status of the certificate renewal using the /api/v1/certificates endpoint.

    Verifying the Renewal

    After renewing the certificates, ensure the following:

    1. Correct Certificate is Applied: Use the NSX Manager UI, CLI, or API to verify the certificate’s details and check the expiry date.
    2. Check System Health: Ensure there are no errors related to certificate validity or communication failures between NSX components.
    3. Network Traffic: Verify that secure communication (via SSL/TLS) between NSX Manager, Edge appliances, and controllers is working correctly.

    Conclusion

    Renewing NSX-T local certificates is crucial to maintaining the security and integrity of your NSX environment. Whether you’re using self-signed certificates or CA-signed certificates, the process involves generating a new certificate (either manually or automatically), uploading the signed certificate, and ensuring all NSX components (Manager, Edge, Controllers) are correctly configured. Always ensure that you take necessary backups, verify your configuration, and restart components as required after renewing certificates.

  • Connecting Two NSX Instances with BGP

    This quick article focusing on Connecting 2 NSX EDGEs via dynamic routing protocol. BGP (Border Gateway Protocol) in this case.

    Connecting two NSXinstances using BGP is an essential practice in larger, distributed network environments. BGP helps with dynamic routing between multiple NSX instances, enabling them to share routing information and automatically adjust paths in case of network failures.

    Initial requirements:

    • Ensure both NSX instances are deployed and operational.
    • The NSX Edge devices should be configured and ready to support BGP.
    • IP connectivity between the two NSX Edge routers in place. Check connectivity with ICMP for example.
    • A BGP ASN (Autonomous System Number) for each NSX instance wil be configured. Make sure you planning it properly. Use ASN from 65XXX.

    Steps to Connect Two NSX Instances with BGP

    1. Login to NSX Manager: Access the NSX Manager web interface of both NSX instances.

    2. Configure BGP on NSX Edge: Navigate to the NSX Edge configuration page on both instances. You will need to configure the BGP settings on the Edge routers that are connected to each network.

      • Go to System > Routing > BGP.
      • Click Add to create a new BGP configuration.

    3. Assign BGP ASN: On each NSX Edge, specify the BGP ASN (Autonomous System Number) unique to each instance. Make sure the ASNs are different for each NSX instance to avoid conflicts. Use ASN from 65XXX.

      Im my case I will use:

      • NSX Instance 1: ASN 65051
      • NSX Instance 2: ASN 65052

    4. Set BGP Neighbor Configuration: Under the BGP configuration, you need to specify the neighbor IP address (the IP address of the remote (second) NSX Edge), as well as the remote ASN of the opposite NSX EDGE.

      In my LAB it is:

      • NSX Instance 1:
        • Neighbor IP: 172.17.5.2
        • Remote ASN: 65052
      • NSX Instance 2:
        • Neighbor IP: 172.17.5.1
        • Remote ASN: 65051

    5. Configure Networks to Advertise: Decide which networks each NSX Edge will advertise to the other NSX instance. We can do rout-map filtering as well, if required. It allows to control exchanging the routes between EDGEs.

    6. Enable BGP: Ensure you enable the BGP session on both NSX Edges. Check the "Enable BGP" box and save the configurations.

    7. Verify BGP Session: Once the BGP session is established, verify the session status from the NSX Edge interface:

      • Go to System > Routing > BGP.
      • Ensure the BGP session is Established and that the advertised routes are visible under the Routing Table.

    8. Monitor and Troubleshoot:

      • You can use tools like show bgp summary or show bgp neighbor from the NSX CLI for troubleshooting.
      • If the session does not come up, verify IP reachability between the two NSX Edges and check for any misconfigurations in ASNs or neighbor IPs.
      • In my experince it is easy task allow dynamically exchange routing information and automatically adjust paths based on network changes.

    Always practice on the LAB before implementing in production.

    Any questions, feel free to reach me out. Always happy to help :)
AustIT Remote Support

Popular tag

Who's Online

We have 77 guests and no members online

Google AdSence

AUST IT - Computer help out of hours, when you need it most.

Find out why we do it for less.

About

AUST IT will help you resolve any technical support issues you are facing onsite or remotely via remote desktop 24/7. More...

Contacts

Reservoir, Melbourne,
3073, VIC, Australia

Phone: 0422 348 882

This email address is being protected from spambots. You need JavaScript enabled to view it.

Sydney: 0481 837 077

Connect

Join us in social networks to be in touch.

Newsletter

Complete the form below, and we'll send you our emails with all the latest AUST IT news.