vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Topology for the customer gateway cluster](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/nsx-t-3-ra-diagrams-customer-edge-cluster-t0-t1.svg)

Figure 4. Topology for the customer gateway cluster

Zoom

![Gateway cluster topology](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/nsx-t-3-ra-diagrams-management-edge-cluster-t0.svg)

Figure 5. Gateway cluster topology



 Tier 0 logical gateway 

An NSX-T Tier-0 logical gateway provides a gateway service between the logical and physical networks (for north-south traffic). In this design, two highly available T0 gateways are deployed in two separate NSX-T gateway clusters, one for customer and one services/managment needs. More services and products are optional for customer chosen topologies and they use the services T0 for their inbound or outbound connectivity needs. Each T0 logical gateway is configured with two uplinks for private and two for public. Additionally, VIPs are assigned to both public and private uplinks.





 Tier 1 logical gateway 

An NSX-T Tier-1 logical gateway has downlink ports to connect to NSX-T Data Center logical switches and uplink ports to connect to NSX-T Data Center Tier-0 logical gateways. They run in the kernel level of the hypervisor they are configured for, and they are virtual router instances (vrf) of the NSX-T gateway cluster. In this design, one or more T1 logical gateways can be created for the needs of customer chosen topologies.





 Tier 1 to Tier 0 route advertisement
[Use an NLB 1.0 to load balance apps in a multizone cluster](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_loadbalancer_planning_multizone.png)

Figure 2. Use an NLB 1.0 to load balance apps in a multizone cluster



1. A request to your app uses the [DNS subdomain](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer_hostname) for your NLBs. You can also access the NLB in each zone by using its public IP address and port on the worker node. Note that by default, each NLB 1.0 is set up in one zone only. To achieve high availability, you must deploy an NLB 1.0 in every zone where you have app instances.
2. A DNS system service resolves the subdomain to the portable public IP address of one of the NLBs and its assigned port on the worker node. Requests are handled by the NLBs in various zones in a round-robin cycle.
3. The NLB receives the request and forwards it to the private IP address of the app pod over the private network. The source IP address of the request package is changed to the public IP address of the worker node where the NLB pod runs. Each NLB routes requests to the app instances in its own zone and to app instances in other zones. Additionally, if multiple app instances are deployed in one zone, the NLB routes the requests between the app pods in the zone.
4. When the app returns a response packet, it uses the IP address of the worker node where the NLB that forwarded the client request exists. The NLB then sends the response packet to the client.









 Components and architecture of an NLB 2.0 

The NLB 2.0 is a Layer 4 load balancer that uses the Linux kernel's IP Virtual Server (IPVS).
Currently, Active-Active mode with T0 is not supported in IBM Cloud® Virtual Private Cloud.

When T0 is run in Active-Standby mode, both participating Edge Transport Node has their own uplink. High availability between these uplinks uses a High Availability VIP.

The T0 is configured with two uplink types: two uplinks for private use and two uplinks for public use. HA VIPs are assigned to both public and private uplinks for high availability. For public and private uplinks, two VPC subnets are needed. These subnets are provisioned from the Zone prefix, and they can both use RFC 1918 private addresses, including the public subnet.



Table 1. VPC subnets for NSX-T T0 uplinks

 Subnet name System traffic type Subnet sizing guidance 

 vpc-t0-public-uplink-subnet T0 public uplink subnet /29 or larger 
 vpc-t0-private-uplink-subnet T0 private uplink subnet /29 or larger 



If you do not need inbound traffic from the internet, you do not need public uplink subnet.

The following VLAN interfaces are required in VPC for each T0 uplink. It is important to separate the public and private uplinks as specified previously. VLAN interfaces with Allow IP spoofing and Enable Infrastructure NAT set to false allow public floating IP addresses to traverse non-NATted to the public uplinks of the T0 logical router. VLAN interfaces with Allow IP spoofing and Enable Infrastructure NAT set to true allow VMware workloads on NSX-T overlay with private IP addresses to be routed to IBM Cloud VPC. These functionalities cannot be combined into one.



Table 2. VLAN interfaces for T0 uplinks

 Interface name Interface type VLAN ID Subnet Allow float Allow IP spoofing Enable infra NAT NSX-T interface Segment name 

 vlan-nic-t0-pub-uplink-1 vlan 700 vpc-t0-public-uplink-subnet true false false T0 Public Uplink * Edge 1 vpc-zone-t0-public-vlanid
1. The automation deploys an NSX-T T0 Gateway in the NSX-T workload edge cluster. The T0 gateway provides connectivity to the IBM Cloud private network.
2. The automation deploys an example NSX-T overlay topology with a T1 Gateway and a few example segments attached both to the T1 and T0 Gateways. You can customize the topology based on your needs.
3. Workload T0 Gateway has a private uplink that is attached to the IBM Cloud private VLAN with three IP addresses, two for uplinks in edge 1 and edge 2 and one for HA VIP. Interfaces are configured with the network mask of the private portable subnet.

The NSX-T T0 uplink does not support secondary IP addresses.
4. You can configure DNAT rules on T0 or T1 for ingress access, or SNAT for egress access from NSX-T overlay by using the IP addresses from the private portable subnet configured in the T0 uplinks. You can also configure load balancer VIPs, IPsec, or L2 VPN. Each of these are advertised as /32 host IP addresses. You need to enable route advertisements on T1 Gateways so that T0 is aware of these IP addresses, and they must appear on T0s routing table.
5. T0 Gateway uses proxy ARP on the uplink subnet for each /32 IP address that is aware of (that is, which exists in its routing table). BCR can route ingress traffic only to these IP addresses. To check the routing table of T0, use the NSX-T GUI or login to NSX-T edge node and its T0 Service Router (SR) VRF.







 Ingress private connectivity with gateway cluster 

Private ingress connectivity to NSX-T overlay is enabled through NAT or though using overlay tunnels. You can use IP addresses from the private portable subnet that is provisioned for T0 private uplinks for these use cases.
The access to private network is provided through private uplinks, which are attached to a portable subnet on a private primary VLAN on the IBM Cloud private network. The routing to IBM Cloud services uses these uplinks. The automation provisions the IP addresses to the uplinks from the IBM Cloud managed 10/8 address space.
5. If you provision your instance with public interfaces, the access to public network is provided through public uplinks. These uplinks are attached to a portable subnet on a public VLAN on the IBM Cloud public network. The routing to internet uses these uplinks, and the public IP addresses to the uplinks are provisioned by the automation.
6. A single Tier-1 Gateway is provisioned by the automation for the workloads. You can use this topology or customize it by provisioning new Tier-1 Gateways.
7. You can expand the default topology by adding new segments to the existing Tier-1 Gateway (or to the new Tier-1 Gateways provisioned by you). The route advertisements between T1 and T0 gateways are fully customizable by you and are done by NSX-T. No routing protocol is required or used between T1 and T0 advertisements.



The following diagram shows an example of a customer deployment that uses the standard topology, when the segments are attached directly to the Tier-0 Gateway. You can add more segments to the Tier-0 Gateway or and delete the Tier-1 Gateway that is deployed by the automation, if needed.





 Related links 



* [IBM Cloud compliance programs](https://www.ibm.com/cloud/compliance)
2. The automation deploys an example NSX-T overlay topology with a T1 Gateway and a few example segments attached both to the T1 and T0 Gateways. You can customize the topology based on your needs.
3. Workload T0 Gateway has a private uplink that is attached to the IBM Cloud private VLAN with three IP addresses, two for uplinks in edge 1 and edge 2 and one for HA VIP. Interfaces are configured with the network mask of the private portable subnet.

The NSX-T T0 uplink does not support secondary IP addresses.
4. When you order a private portable subnet to a private VLAN that is routed by vSRX, BCR routes this subnet to the vSRX though its transit VLAN.
5. Instead of configuring the subnet as a secondary IP address in the interface in vSRX, you can route this subnet to the NSX-T T0 HA VIP.
6. You can then use this subnet in segments or specific IP addresses from it for NAT rules, load balancer VIPs, or VPN endpoints.







 Private connectivity through direct link 

Private connectivity for vCenter Server can use [IBM Cloud Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-dl-about) and tunneling. This solution is applicable for [NSX-T based vCenter Server instance](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverview), which is provisioned in IBM Cloud classic infrastructure. You can use Gateway Appliance or vCenter Server gateway cluster with Juniper vSRX or other device as part of the solution as an option.

The tunnel is established between NSX-T T0 and a customer router routable through Direct Link. If vSRX or other third-party device is used in gateway cluster, you can terminate the tunnel in these devices as well. In this case, NSX-T T0 advertises routes in the vSRX (or other third-party device) through BGP or Static Routes.
[Multisite – single tenant example topology](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/v2t-diagrams-2-zone.svg)

Figure 4. Multisite – single tenant example topology



1. The vCenter Server automation deploys a single site solution, which can be manually expanded to support the target multisite topology. The deployment includes a single vCenter and three NSX-T Managers that are deployed on the cluster on the initial IBM Cloud data center location. You must expand the compute capacity to have resources available in the other IBM Cloud data center or zone in the specific IBM Cloud multizone region.
2. The vCenter Server automation deploys two edge cluster transport nodes and a single edge cluster for your Tier-0 and Tier-1 gateways. You do not need the default Tier-1 Gateway, and it can be removed.
3. In the initial IBM Cloud data center, access to private network is provided though private uplinks, which are attached to a portable subnet on a private primary VLAN on the IBM Cloud private network. If you provision your instance with public interfaces, access to public network is provided though public uplinks. They are attached to a portable subnet on a public VLAN on the IBM Cloud public network. The uplinks have specific IP addresses to this data center and they cannot move between the data centers.
4. You must deploy two additional edge cluster transport nodes manually. Also, you must create a new edge cluster for your Tier-0 and Tier-1 gateways in the second IBM Cloud data center hosts.
5. In the second IBM Cloud data center, access to private network is provided though private uplinks, which are attached to a portable subnet on a private primary VLAN on the IBM Cloud private network. If you provision your instance with public interfaces, access to public network is provided though public uplinks, which are attached to a portable subnet on a public VLAN on the IBM Cloud public network.
(https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_loadbalancer_planning.png)

Figure 1. Expose an app in a single-zone cluster by using an NLB 1.0



1. A request to your app uses the public IP address of your NLB and the assigned port on the worker node. Note that if you [create a DNS subdomain](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer_hostname) for your NLB, users can access your app through the NLB's subdomain instead. A DNS system service resolves the subdomain to the portable public IP address of the NLB.
2. The NLB receives the request and forwards it to the private IP address of the app pod over the private network. The source IP address of the request package is changed to the public IP address of the worker node where the NLB pod runs. If multiple app instances are deployed in the cluster, the NLB routes the requests between the app pods.
3. When the app returns a response packet, it uses the IP address of the worker node where the NLB that forwarded the client request exists. The NLB then sends the response packet to the client.







 Traffic flow in a multizone cluster 

The following diagram shows how a network load balancer (NLB) 1.0 directs communication from the internet to an app in a multizone cluster.

Zoom

![Use an NLB 1.0 to load balance apps in a multizone cluster](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_loadbalancer_planning_multizone.png)

Figure 2. Use an NLB 1.0 to load balance apps in a multizone cluster



1.
5. If you provision your instance with public interfaces, the access to public network is provided through public uplinks, which are attached to a portable subnet on a public VLAN on the IBM Cloud public network. The routing to internet uses these uplinks, and the public IP addresses to the uplinks are provisioned by the automation.
6. You can expand the default topology by adding new segments to the existing Tier-0 Gateway. You can delete the Tier-1 gateway that is deployed by the automation, if not needed in your topology.







 Single-site – multitenant 

Single-site – multitenant pattern provides a simple highly scalable pattern if you need multiple tenants (for example, different business units), which require route table isolation or have conflicting IP address spaces. This deployment pattern uses the base topology that is provided by IBM Cloud vCenter Server automation, which includes single Tier-0 and Tier-1 Gateways and a few NSX-T overlay segments as a starting point. If you have multiple tenants, you can divide them by using multiple Tier-1 Gateways and by controlling routing advertisements, and use network address translation (NAT).

The following diagram shows an example of a multitenant deployment by using the standard topology. Also, it shows how to expand it for a simple multitenant pattern. You can manually deploy multiple Tier-1 Gateways through NSX-T and add each tenant segment to their own Tier-1 Gateway.

Zoom

![Single-site – multitenant example topology](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-1-zone-t1-mt.svg)

Figure 3. Single-site – multitenant example topology



1. The vCenter Server automation deploys an example single-site topology, which follows the principles that are presented in this model. The deployment includes a single vCenter and three NSX-T Managers that are deployed in the cluster on the initial IBM Cloud data center location.
2.
Requests from sources in your Satellite location are made to the Satellite Link connector host name and the port, such as nae4dce0eb35957baff66-edfc0a8ba65085c5081eced6816c5b9c-c000.us-east.satellite.appdomain.cloud:30819. This Link host name and port are mapped to the destination resource's domain and port.
2. The Satellite Link connector forwards the request to the Satellite Link tunnel server on the Satellite control plane master over a secured TLS connection.
3. The Satellite Link tunnel server resolves the request to the destination's IP address and port, and forwards the request to the destination resource.







 Location endpoint 

By default, source clients that are connected to the IBM Cloud private network cannot reach destination resources that run in your Satellite location because the destination resource's IP address is not routable from outside the location. Review the following architecture diagram and steps, which demonstrate how Satellite Link enables communication from services that are connected to the IBM Cloud private network to locations through Satellite endpoints.

Zoom

![Network traffic through Satellite Link.](https://cloud.ibm.com/docs-content/v1/content/c8335d66af691d19e837116fd633481c477061eb/satellite//images/sat_link_location1.svg)

Figure 2: Network traffic flow from an IBM Cloud source to a destination resource in your location through Satellite Link



1. When you create an endpoint for a resource that runs in your Satellite location, a port is opened on the Satellite Link tunnel server and added in the endpoint configuration. Requests from sources that are connected to the IBM Cloud private network are made to the Satellite Link tunnel server host name and this port, such as c-01.us-east.link.satellite.cloud.ibm.com:30819. This Link host name and port are mapped to the destination resource's domain and port.
2. The Satellite Link tunnel server resolves the request to the Satellite Link connector host name and endpoint port, and forwards the request to the Satellite Link connector over a secured TLS connection.
The NSX-V logical switches do not support VLAN tagging, so only one logical switch can be connected to the edge node's interface. For this reason, one edge cluster (two edge nodes) is required for each NSX-V logical switch that requires L2 extension.

The default MAC address of the NSX-T virtual-distributed router needs to be changed so that it does not conflict with the one used by the NSX-V Distributed Logical Router (DLR). The virtual-distributed routers in all the transport nodes of an NSX-T environment use the default global MAC address, which is required even if the NSX-V DLR interface is disabled for that logical switch. For more information, see [Change the MAC Address of NSX-T Virtual Distributed Router](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/migration/GUID-538774C2-DE66-4F24-B9B7-537CA2FA87E9.html).

The overlay segments in NSX-T must have the same virtual network identifier (VNI) as the Logical Switches in NSX-V. You must use the NSX-T APIs to create the overlay segments. You cannot create overlay segments with the same VNI in the NSX Manager UI.

The NSX-T Edge node VM can be deployed on any ESXi host as it has its own TEP. The ESXi host can be NSX-V prepared.

VMs running on NSX-V prepared hosts never see the VXLAN encapsulation. The ESXi host's NSX-V VTEP de-encapsulates VXLAN before it sends data to the VM. The NSX-T Edge node VM running on an NSX-V prepared host sees frames without encapsulation on the NSX-V logical switch (virtual wire) and can send these frames to the NSX-T segment.
Architecture pattern for using Direct Link with NSX-T edge cluster in colocation 

On [VMware vCenter Server](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverview) instance in IBM Cloud® classic infrastructure, your workloads are deployed and run on VMware NSX-T™ overlay networks. As part of the deployment, the automation deploys an example NSX-T topology. You can use the provisioned examples as your base or build your own topologies on overlay. These overlay networks are not automatically advertised to IBM Cloud classic infrastructure network.

This architecture pattern presents private connectivity for VMware vCenter Server® that uses [IBM Cloud Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-dl-about) and deploying an NSX-T edge transport node at the colocation. This solution is applicable for [NSX-T based vCenter Server instance](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverview), which is provisioned in IBM Cloud classic infrastructure.

This solution relies on the principle that you can advertise NSX-T TEP traffic through Direct Link to the colocation. Therefore, you can extend your NSX-T overlays over Direct Link. You are responsible for deploying the edge transport nodes in colocation on your own x86 hardware and for creating the NSX-T edge cluster and configuring Tier-0 (T0) Gateway on the edge cluster.

You can use Gateway Appliance or vCenter Server gateway cluster with Juniper vSRX or other device as part of the solution. This is optional.



 Deploying Direct Link with NSX-T edge cluster in colocation 

The following diagram presents an overview of an architecture pattern for deploying Direct Link with NSX-T edge cluster in colocation.

Zoom

!
Configuration migration 

Configuration migration covers all the NSX-V settings and parameters that must be transferred to the VMware NSX-T™ environment to provide similar functions of the NSX-V environment.

Depending on the complexity of your network, this can include as follows:



* VLAN and overlay-backed logical switches.
* L2 Bridges, routing, and NAT.
* Transport zones.
* Distributed and edge firewall.
* L2 and L3 VPNs.
* Load balancer, DHCP, and DNS.
* Service composer, guest, and network introspection.
* Grouping objects, IP and MAC sets, security groups, tags, services and service groups.



Configurations can be applied by one of the following approaches:



* Manual or scripted - By using the NSX-T UI or scripting tools like Terraform, the NSX-T configuration can be applied to the required overlay pattern.
* Migration Coordinator - Migration Coordinator is a built-in and automated migration tool, which is designed to help migrate from NSX-V to NSX-T. This tool is fully supported by VMware® and is built into NSX-T Manager Appliance. Migration Coordinator might also be used as an assessment tool to check whether the existing NSX-V environment is suitable for migration with Migration Coordinator. This is nondisruptive and doesn't change the NSX-V infrastructure.
* Third-party tool - It provides UI based scripts to enable the assessment, migration, and rollback of configurations. For more information, see [NSX-V to NSX-T migration tools](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-v2t-l2-nsx-t).



If the configurations are simple, or there are not too many rules or definitions, manual, or scripted is typically the simplest way to migrate the configuration. If the configurations are complex, consider the use of a third-party tool.

Migration Coordinator supports other migration approaches such as "in-place migration", which is not supported in IBM Cloud®.