• 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 - 4 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 :)

  • Renewing NSX-T Local certificates

    This article focusing on the main piont to help to renew the local NSX-T sertificates:
     
    Use REST API requests by Postman for example.
    use admin credentials to make API requests.
     
    STEP x: Generate self signed certificate:
    Make sure that when this certificate was imported, the option Service Certificate was set to No
     
    STEPx: Validate the cetrificate:
    - The basic API call for this is: GET https://<nsx-mgr>/api/v1/trust-management/certificates/<cert-id>?action=validate>
    Responce shuld be: "status": "OK"
      
    POST https://<nsx-local-mgr>/api/v1/trust-management/certificates?action=set_pi_certificate_for_federation
{
    "cert_id": "c5f13ec0-8075-441e-80b5-aeb707f6b87e",
    "service_type": "LOCAL_MANAGER"
}
     
     
    Main article for more information:
     
    After implementation test:
    Search the cert ID and section "used_by" should represent where the cert is in use.

  • NSX-T randomly stopped services

    If you experining the SSH unavaliability on the NSX-T, probably one of the reason is that SSH serivece not running,
    To start SSH servces on the NSX-V, you have to use vCenter to havedirect access to the NSX applience.

  • VeloCloud initial CLI setup

    CLI Activation procedure (undocumented):
    reset_config.sh - reset the SDWAN unit configuration to factory default.
    set_wan_config.sh SFP1 STATIC 172.16.0.10 255.255.255.0 172.16.0.254 -V XXX  - setup IP address on the SFP1 for vlan XXX.
    activate.py -s vcoYYY-syd1.velocloud.net XXX-YYY-ZZZ-RRR - activate velocloud unit.
     
    Addidional useful CLI commands:
    debug.py --link - provides status of the interfaces and IP addresses assigned.
    debug.py --ha verp - check HA status.
    tcpdump.sh -i any host IPADDRESS - capturing traffic on the SDWAN unit based on cryterias source/destination
    tcpdump.sh -nNvi sfp1.XXX proto icmp- capturing ICMP traffic on the interface.
    grep -i /var/log/mgd.log - check recent logs
    ifconfig sfp1.XXX - check interface configuration.
    /opt/vc/bin/vc_procmon stop - ???.
     

  • NSX-V DB or disk stave issue

    This article related with NSX-V upgrade error appearing during image uploading.
    We are goinig to discuss quickly 2 error possible could appear:
    "Cannot continue upgrade due to errors : Large database table. There are some tables with 5215948 entries, but the recommended table size is 5000000. We recommend running a database full vacuum before proceeding with upgrade. Upgrade aborted.. Please correct before proceeding."
     
    OR
    "Cannot continue upgrade due to errors : Insufficient disk space. 
Database disk usage is at 87%, but it should be less than 70%. 
We recommend running a database full vacuum before proceeding with upgrade. 
Upgrade aborted.. Please correct before proceeding."
     
    If you have NSX-V cross vCenter, the upgade possible will be stalled on both.
     
    During
     
    TRUNCATE TABLE job_instance_task_instances, task_instance_task_data, task_instance_task_output, task_instance, task_task_init_data, task, task_policy, task_target, job_instance_job_output, job_instance, job_data_task_dependency_map, task_dependency_tasks, dependent_task,job_data, job_schedule, task_dependency, housekeeping_module;

  • NSX-v Apache Log4j voulnerability patching steps

    This article will discuss critical vulnerabilities in Apache Log4j identified by CVE-2021-44228 and CVE-2021-45046 in VMware NSX-V.
    Overall steps desctibed on the VMware official page, however, I had to search some details separatly to apply and test the patch.
    Lets go trough the steps:
     
    PRE-CHANGE ACTIVITIES:
    1. Take a backup of your NSX-V Manager. This is always important step. One day it will save your live :), so please take time and do it properly.
    2. Download the patch file from official VMware website signed_bsh_fix_log4j.encoded
     
    CONFIRMING VOULNERABILITY IS PRESENT:
    To confirm the voulnerability is present, we need to initiate test attack to the NSX-V manager.
    Voulnerabiluty code will be sent by POSTMAN and result of the NSX-V behavior will be caprured by TCPDUMP running directly on the NSX-V manager.
     
    1. SSH to the NSX-V to the root level (Engineering mode).
    Additional information how to login in Engineering mode could be found here: https://austit.com/faq/324-nsx-engeneering-mode
    If you experiencing isssues with SSH connectivity to the NSX-V manager, some troubleshooting steps could be found here: https://austit.com/faq/353-nsx-v-enable-ssh
    2. Run next tcpdump command:
    tcpdump -i lo -s 1500 -XX port 389
    3. Using POSTMAN, post REST API to https://<NSX-Manager-IP>/api/2.0/services/securitygroup/globalroot-0
    Authentication: Basic Auth (Username: admin)
    Headers: Content-Type - application/xml
    Body:
    <securitygroup>

    </securitygroup>
    4. My result after th POST request on the POSTMAN:
    securitygroup-17
    5. My result fot TCPDUMP automatically appeared on the screen (patched system should not capture any traffic):
    12:10:01.529110 IP localhost.36158 > localhost.ldap: Flags [S], seq 724932146, win 43690, options [mss 65495,nop,nop,sackOK,nop,wscale 7], length 0
    0x0000: 0000 0000 0000 0000 0000 0000 0800 4500..............E.
    0x0010: 0034 551f 4000 4006 e7a2 7f00 0001 7f00 .4U.@.@.........
    0x0020: 0001 8d3e 0185 2b35 9632 0000 0000 8002...>..+5.2......
    0x0030: aaaa fe28 0000 0204 ffd7 0101 0402 0103...(............
    0x0040: 0307 ..
    12:10:01.529138 IP localhost.ldap > localhost.36158: Flags [R.], seq 0, ack 724932147, win 0, length 0
    0x0000: 0000 0000 0000 0000 0000 0000 0800 4500..............E.
    0x0010: 0028 0000 4000 4006 3cce 7f00 0001 7f00 .(..@.@.<.......
    0x0020: 0001 0185 8d3e 0000 0000 2b35 9633 5014.....>....+5.3P.
    0x0030: 0000 61a2 0000 ..a...
     
    PATCHING SYSTEM:
    Patching will be applied over POSTMAN REST API.
     
    1. Using POSTMAN, post REST API to https://<NSX-Manager-IP>/api/1.0/services/debug/script
    Authentication: Basic Auth (Username: admin)
    Headers: Content-Type - application/xml
    Body:
    Select 'Binary' as body type and attach the file signed_bsh_fix_log4j.encoded
    4. My result after th POST request on the POSTMAN is "1".
    Starus 200 OK.

    CONFIRMING NO VOULNERABILITY anymore:
    To confirm the voulnerability patch was installed successfuly, we need to initiate test attack to the NSX-V manager.
    Voulnerabiluty code will be sent by POSTMAN and result of the NSX-V behavior will be caprured by TCPDUMP running directly on the NSX-V manager.
     
    1. SSH to the NSX-V to the root level (Engineering mode).
    Additional information how to login in Engineering mode could be found here: https://austit.com/faq/324-nsx-engeneering-mode
    If you experiencing isssues with SSH connectivity to the NSX-V manager, some troubleshooting steps could be found here: https://austit.com/faq/353-nsx-v-enable-ssh
    2. Run next tcpdump command:
    tcpdump -i lo -s 1500 -XX port 389
    3. Using POSTMAN, post REST API to https://<NSX-Manager-IP>/api/2.0/services/securitygroup/globalroot-0
    Authentication: Basic Auth (Username: admin)
    Headers: Content-Type - application/xml
    Body:
    <securitygroup>

    </securitygroup>
    4. My result after th POST request on the POSTMAN:
    Status: 404 Not Found
    5. My result fot TCPDUMP shows no output.
     
    Hope it helps, HAPPY PATCHING.

  • VMware NSX-T Avi Networks Load Balancer Installation and initial configuration

    This article will discuss VMware NSX-T Avi Networks Load Balancer Installation and initial configuration.
    Let's start with simple OVA deployment, assuming you already download the controller-21.1.1-9045.ova file:
     
    1. Start deploying the downloaded image:
    AVI01
    2. Select friendly name and appropreate folder.
    3. Select compute and image validation will happened.
    4.

  • NSX-T Password expired issue

    Just recently connected to my test NSX-T environment and found that my password is espired.
    Actually it is admin credentials. See picture below:
     
    NSXT password expired
     
    Fix is eazy, just SSH to the host and update the admin passwrd.
     
    You are required to change your password immediately (password aged)
    WARNING: Your password has expired.
    You must change your password now and login again!
    Changing password for admin.
    (current) UNIX password:
    New password:
    Retype new password:
     
    After updating the password over CLI, you can successfuly login over UI.
     
    Password expiration is 90 days by default.
     
    To avoind this issue in the future we can extend expiration dates using next command:
    set user admin password-expiration 9999
     
    To check the expiration date:
    get user admin password-expiration
    Thu Nov 09 2021 UTC 00:36:18.240
    Password expires 9970 days after last change. Current password will expire in 9970 days.

  • NSX-V to NSX-T Migration: universal objects

    We are planning to process with NSX to vSphere to NSX-T migration.

  • NSX-T issue: Some appliance components are not functioning properly

    One of the NSX-T nodes reporting "Some appliance components are not functioning properly" and web page is down.

  • Deploy OVF from datastore

    Deploying OVF file is straight forward process. 
     
    DeployOVF01.PNG
    But if you have slow link to the managed environment, how you can deploy OVF from internal storage.
    Lets assume you can copy/get the OVF file to the datastore. How we can point the OVF deployment to the file located in the Datastore?
     
    So, just login to the vCenter or ESXi host to the https://HOST/folder and copy the url for file.
     
    DeployOVF02.PNG
    Another issue you could face is that OVF deloyment like to have ".ovf" at the end.
    DeployOVF03.PNG
     
    Let's put tdo the trick and add "&f.ovf" at the end.

    DeployOVF05.PNG
    Now we can continue our OVF deployment...
     

  • ICMP issue troubleshooting between esxi guests

    Issue recently appeared that 2 guests out of 50 not response to ICMP from another vCenter VMs.

    Source and destination on the same proadcast domain stratched accross all vCenters.

    All VMs in the same vCenter can communicate with no issues.

    Just 2 VM experiencing issues.

    MAC address appeared on the source VM.

    Checked mac address table on all equipements, looks ok.

    Next step to do packetcap on vmnic of destination VM.

     

     
AustIT Remote Support

Popular tag

Who's Online

We have 51 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.