All Posts

The design which the documentation refers to is this: BGP North-South Routing for VMware Cloud Foundation Instances with Multiple Availability Zones In short: You'll have two Edge nodes running in AZ1 which are protected with vSphere HA and in case of a failure would failover to AZ2. They peer with a routing device in AZ1 and AZ2 respectively and have traffic steering enabled so that e- and ingress is in AZ1 primarily.   From network perspective this is a bad design and leads into long service interruption in case AZ1 fails. I would rather expand this cluster with a second pair of Edge nodes, keep them in AZ2 and peer it accordingly without traffic steering enabled. You'll end up having asymmetric routing but advantages of having almost zero failover time because you'll have active components in every AZ running (no need for failing over Edge nodes between AZ).

I assume you either have a stretched cluster or two site local clusters in VCF but in both cases your intention is to span a Tier-0 GW across the two sites. For redundancy and performance reasons I would create an Edge cluster with 4 Edge nodes total, two per site. Depending if your uplink VLANs are stretched across both sites or if they are only available within each site: - All Edges in AZ1 and AZ2, in essence the Tier-0 GW, have their uplink interfaces in the two stretched uplink VLANs. All Edge nodes peer with a router in AZ1 and AZ2 through both uplink VLANs, 4 peers in total. - Each pair of Edge nodes, in essence the Tier-0 GW, have their uplink interfaces in the two site local uplink VLANs in AZ1 and AZ2 respectively. Edge nodes in AZ1 peer with a router in AZ1 and Edge nodes in AZ2 respectively, 4 peers in total. For both cases: Depending on how you wan't your traffic carried to your physical network, you might use traffic steering options in BGP like local preferences and AS path prepending to have e- and ingress traffic though AZ1 primarily. Or you don't steer your traffic but you'll have asymmetric routing (which doesn't need to be negative).

Hi,   what you're asking for is named Fault Tolerance VMs. AFAIK it's not supported in combination with vSAN stretched Cluster, but I'm happy to get corrected. As an Fault Tolerance protected VM requires another "shadow" VM which is in sync (Files & Disk, RAM Content, CPU Registers...) that feature does really require a superfast and low latency link between the nodes which would host those paired VMs.

Hello, Kindly allow me to understand your scenario by answering the below: - VCF is stretched from VSAN perspective so far correct? Yeah that's right - What is your use case from networking perspective between the two sites? A/A ? A/P ? Activate/Activate - What is your expectation about the failure scenario from Site A to Site B from time perspective? Let the VMs move and be able to maintain IP addressing   Regards

Hello, kindly allow me to understand your scenario by answering the below: - VCF is stretched from VSAN perspective so far correct ? - What is your use case  from networking perspective between the two sites ? A/A ? A/P ? - What is your expectation about the failure scenario from Site A to Site B from time perspective ?  

Recommendation To test the MTU size of 9,000, the database was running an OLTP workload while the virtual machine was moved using vMotion to another server. We captured the time to vMotion the server as well as New Orders per Minute (NOPM) and Transactions per Minute (TPM) for analysis. Increasing the MTU size showed significant gains for these metrics: vMotion time to complete NOPM TPM A larger MTU size of 9,000 reduced the time to complete moving the database with an active workload compared to the default MTU size of 1,500. This impressive time-saving function led us to label this best practice as a Day 1, Highly Recommended procedure.  NOPM and TPM also increased, but not as substantially as the vMotion time savings. The overall benefit of this best practice is that database performance has greater consistency during vMotion with a substantial time-savings in moving the database.  Implementation Steps Process to configure MTU size = 9000 for vMotion network Configure MTU Size = 9000 at vMotion Distributed Switch To change at vMotion distributed switch level, select the distributed switch for vMotion in networking tab in vSphere and select setting In the Edit setting, select Advanced and change the MTU to 9000 Click OK to save the change Configure MTU Size = 9000 at VMKernel Adapter Login to vSphere and select the EXSi host, and click the Configure tab  Select the VMkernel adapters  Under VMkernel adapters, select the Motion network and click Edit In the Edit Settings, under VMkernel port settings, change the value of MTU from 1500 to 9000. Click OK to save the change Repeat the same steps above on another host Configure MTU Size = 9216 at Physical Switch To change at switch level, show running configuration interface ethernet (Run this to find port rang Configure Terminal Interface range ethernet "enter the port range" (eg:1/1/25 -1/1/2 mtu 92 Exit Write memory to save the configuration Note: To change it at network switch level, login into switch console and update the MTU

Thank you for documenting this. I was leaning towards creating a new vlan TZ.  And applying to the nodes using the Transport Node Profile that VCF created.  Is  attaching, or detaching, the TNP to a Baseline WLD disruptive?  I assume in this case only adding additional TZ to the nodes, so it won't take VMs or nodes offline.

Here are some steps you can take: NSX-T Load Balancer Configuration: Check the NSX-T load balancer configuration for the vROps cluster. Make sure that the load balancer is properly configured with the correct virtual server, pool, and health check settings. Confirm that the pool members (vROps nodes) are added correctly and their status is healthy. Health Checks: Verify that the health check monitors defined in NSX-T are configured properly. The health check monitors should be configured to check the correct services on the vROps nodes, and they should match the services that are configured to listen on the vROps cluster IP. Firewall Rules: Review the firewall rules within NSX-T to ensure that traffic to the vROps cluster IP is allowed. Both inbound and outbound rules might need to be reviewed to ensure proper communication. Network and Routing: Check the network and routing configurations. Ensure that there are no routing issues preventing traffic from reaching the vROps cluster IP. Check if any network segments or routes need to be configured in NSX-T to allow proper communication. DNS Resolution: Confirm that the DNS records for the vROps cluster IP and FQDN are correctly configured and resolving to the appropriate IP addresses. DNS issues can lead to communication problems. vROps Node Health: Verify the health of individual vROps nodes. If one of the nodes is experiencing issues, it might affect the overall cluster accessibility. Check the vROps management console for any alerts or errors. NSX-T Logs and Monitoring: Monitor NSX-T logs and events related to load balancer activity. This can provide insights into any issues that might be occurring at the network level. vROps Logs: Check the vROps logs for any errors or issues that might be related to the cluster IP accessibility. This could provide additional context about what's happening on the vROps side.

Also read through below 7 minutes blog, would give you much more insight on how to use DFW only feature in NSX-T, https://www.vgarethlewis.com/2022/06/20/vmware-nsx-micro-segmentation-only-deployment/ Credit to Gareth Lewis -Blog