vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If vCenter Server gateway cluster with vSRX (or other third-party device) or IBM Cloud Gateway Appliance is deployed to your classic infrastructure, you must configure your vCenter Server instance Private Primary VLAN. It is routed through the vSRX or Gateway Appliance and allows TEP traffic through it.
4. Create a Direct Link at your IBM Cloud data center or zone location and attach your classic network as a connection. All your classic networks in the region are advertised with Local routing option (or all with Global Option). Use BGP between your colocation router and Direct Link. Ensure that the networks planned for NSX-T edge transport node management and TEP traffic are advertised through this BGP session to Direct Link.
5. Deploy NSX-T edge cluster at colocation and create a T0 at the colocation cluster. Create routes on edge nodes for management and TEP traffic through the Direct Link path.
6. Configure an NSX-T overlay transit segment between T0 VRFs and configure routing between the T0 VRFs.
7. Each tenant has their own WANs or MPLS. You must design and configure how to secure and separate the tenants and connect to tenant WANs.







 Considerations 

When you design or deploy this architecture pattern, consider the following steps:



* This pattern requires BYOL for the colocation solution VMware licensing. Contact VMware or your business partner for licensing details.
* This pattern requires you to bring your own x86 hardware at colocation to host the NSX-T edge transport nodes.







 Related links 



* [Getting started with IBM Cloud Direct Link (2.0)](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl)
* [VMware vSphere overview](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vs_vsphereclusteroverview)
Setting up NSX-T L2 bridge for the migration from NSX-V to NSX-T 

This use case is based on the [Lift and Shift Migration of Specific Parts of NSX Data Center for vSphere](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/migration/GUID-3D173C9C-6BB9-48C3-B543-CF6B19DF4EF1.html) scenario.

The NSX-T Edge node extends the NSX-V logical switch to the NSX-T overlay segment. The Edge Services Gateways (ESG) in the NSX-V environment serve as the default gateway for all north-south traffic from the workload VMs on the logical switch (virtual wire) until it is disconnected from the Distributed Logical Router (DLR), and the NSX-T overlay segment is connected to the Tier-0 (T0) or Tier-1 (T1) gateway. This process switches the default gateway to the NSX-T T0 or T1 gateway, depending on the chosen NSX-T topology. For more information, see [Extending Layer 2 networks with NSX-T Edge bridge](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/migration/GUID-5B9390FB-7E52-4669-AF63-3C3490841432.html).

After all the workloads are migrated from NSX-V to NSX-T, the L2 bridge can be removed or reused for the next logical switch to be migrated.



 Setting up NSX-T L2 bridge in NSX-V environment 

Zoom

![Setting up NSX-T L2 bridge in NSX-V environment](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/v2t-nsx-t-l2-bridge-1.svg)
The vCenter Server automation deploys two edge cluster transport nodes and a single edge cluster for your Tier-0 and Tier-1 gateways.
3. The Tier-0 gateway provides north-south routing capabilities and access to IBM Cloud private network is provided though its uplinks.
4. 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. The routing to IBM Cloud services uses these uplinks. IP addresses for the uplinks are provisioned by automating the 10/8 address space that is managed by the IBM Cloud.
5. 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 routing to internet uses these uplinks and 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 that 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. This 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).

This option is suitable for customers with workloads that run on a multiple data center, single tenant, and have some overlapping IP addresses inside their own workloads.

Overlapping IP addresses refers to overlay segments between customer environments that run on the vCenter Server instance.

The following diagram shows an example of a multitenant deployment by using the standard topology. Also, you can see how to expand that for a simple multitenant pattern.
Note that your resources must be configured for the data encryption protocols that you specify.

Review the following information about how Satellite Link handles each type of connection protocol.

If you use the Satellite console to create an endpoint, the destination protocol is inherited from the source protocol that you select. To specify a destination protocol, use the CLI to create an endpoint and include the --dest-protocol option in the ibmcloud sat endpoint create command.



 TCP and TLS 

If your destination resource does not require requests with a specific HTTP or HTTPS host name header, or can accept direct requests to its IP address instead of its host name, use the TCP or TLS protocols. Satellite Link uses the same protocol as the request to transfer the request packet to the destination.





 HTTP and HTTPS 

If your destination resource is configured to listen for a specific HTTP or HTTPS host name header, use the HTTP or HTTPS protocols. By using HTTP and HTTPS header remapping, Satellite Link is able to correctly route requests for multiple destination resources through TCP ports 80 (HTTP) and 443 (HTTPS).

Cloud endpoint
: Source requests from your Satellite location to your destination resource that runs outside of the location contain an HTTP header such as linkconnector_hostname:port. When the request is sent from the Satellite Link connector to the Satellite Link tunnel server, the Satellite Link tunnel server changes the HTTP header on the request to the destination host name and port, such as dest_hostname:dest_port. The Satellite Link tunnel server then uses the destination's host name and port to forward the request to the correct destination resource.

Location endpoint
: Source requests from clients that run outside the location to your destination resource in your Satellite location contain an HTTP header such as linkserver_hostname:endpoint_port. The Satellite Link tunnel server changes the HTTP header on the request to the destination host name and port, such as dest_hostname:dest_port, and sends the request to the Satellite Link connector. The Satellite Link connector then uses the destination's host name and port to send the request to the correct destination resource.





 HTTP tunnel
If you do not need inbound traffic from internet, you might not need either public uplinks on T0 or the public VLAN interfaces for the bare metal server.

Routing in T0 needs to take the previous note into consideration. If you have public uplinks, your default route 0.0.0.0/0 must be routed through the public uplinks and any private routes must be routed through private uplinks. Configure your static routes to the gateway of your VPC subnet.

You can provision only one pair of uplinks from the T0 Logical Router from the same gateway cluster in the same VPC subnet. This limitation also includes T0 VRFs. Each T0 uplink pair must have its own VPC subnet.





 Tier-1 logical router 

An NSX-T T1 logical router has downlink connections to the attached NSX-T segments and uplink connections to a single T0 logical router. The NSX Edge Nodes provide the compute capacity for the T1 logical routers. Each T1 logical router contains a service router (SR) and a distributed router (DR), same as with T0s. A DR runs as a kernel module distributed in hypervisors and SR is instantiated as a VRF on a gateway cluster when a service is enabled and cannot be distributed.

In this design, one or more T1 logical routers can be created for the needs of your chosen topologies.

You can deploy multiple T1s in the same gateway cluster, but that gateway cluster can have only one T0.





 VPC routing with Tier-0 logical routers 

When designing logical network topologies in IBM Cloud VPC hosted NSX-T, it is important to decide how to route the traffic of NSX-T segment attached workloads between NSX-T, IBM Cloud VPC, and public internet.

The following diagram presents an overview of the routing between NSX-T Logical Routers and VPC.

Zoom

!
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. The vCenter Server automation deploys two edge cluster transport nodes and a single edge cluster for your Tier-0 and Tier-1 Gateways.
3. The Tier-0 Gateway provides north-south routing capabilities and the access to IBM Cloud private network is provided through its uplinks.
4. 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.

Zoom

!
Supported topologies 



 Single data center base topology 

This topology creates a single gateway cluster, with active-passive Tier-0 and Tier-1.

Active-passive on the Tier0 provides IPsec capability for access through the HA VIP address. Alternatively, Tier-0 can use Border Gateway Protocol (BGP) and peer with a vSRX firewall.

The following diagram shows an example of a customer deployment that uses the standard topology, when the segments are attached to the Tier-1 Gateway. You can add more segments to the existing Tier-1 Gateway or more Tier-1 Gateways on the same NSX-T edge clusters, if needed.

Zoom

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

Figure 1. Single-site – single tenant example topology with Tier-1 Gateway



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. The vCenter Server automation deploys two edge cluster transport nodes and a single edge cluster for your Tier-0 and Tier-1 Gateways.
3. The Tier-0 Gateway provides north-south routing capabilities and the access to IBM Cloud private network is provided through its uplinks.
4. 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.
By default, two Satellite Link components, the tunnel server and the connector, proxy network traffic between IBM Cloud and resources in your Satellite location over a secure TLS connection. This document covers the use case of using a TLS connection over Direct Link.

This setup uses the tunnel server's private cloud service endpoint to route traffic over the IBM Cloud private network(166.9.0.0/8, see [Service network](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-ibm-cloud-ip-rangesservice-network). However, communication to the tunnel server's private cloud service endpoint must go through the 166.9.X.X/16 IP address range on the IBM Cloud private network, which is not routable from IBM Cloud Direct Link.

To enable access to the 166.9.X.X/16 range, create a Relay in your IBM Cloud account, which will reverse proxy incoming traffic to the tunnel server's private cloud service endpoint. By default, the Relay Ingress has an IP address in the internal 10.X.X.X/8 IP address range, which is accessible via a Direct Link connection.

The following diagram demonstrates the flow of traffic.

Zoom

![Satellite Link setup that uses a Direct Link connection and a reverse proxy](https://cloud.ibm.com/docs-content/v1/content/c8335d66af691d19e837116fd633481c477061eb/satellite//images/sat_dl_architecture.svg)

Figure 1. Satellite Link setup that uses a DirectLink connection



1. Network traffic originating at your Location, such as a request from an IBM Cloud Satellite cluster to an IBM Cloud service, is routed via Link Service over Direct Link to the Relay Private Ingress, which has a Direct link routable address.
2. The Relay initiates a new session to forward the request to the private cloud service endpoint of the tunnel server, which terminates to an IP address in the 166.9.X.X/16 range (Link private address).







 Objectives 

You can create Red Hat CoreOS enabled Locations without accessing public Internet.
For more information, see [Multizone region data center active-active topology](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vrw-nsxt-topologiesfss-nsx-topologiest-mzraa).
* No stretched L2 capability - The stretching of layer 2 NSX-T overlay segments across sites is not possible.
* Stretched L2 capable - The stretching of layer 2 NSX-T overlay segments across sites is possible by using manual configuration. For more information, see [Multizone region data center active-active topology](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vrw-nsxt-topologiesfss-nsx-topologiest-mzraa).
* Single edge cluster Tier-0 gateway for workloads - The automation deploys a single NSX-T edge cluster, consisting of a pair of edge appliances, hosting an active standby Tier-0 gateway for use by the workload VMs. These VMs provide connection between the overlay and underlay networks.
* Stretched edge cluster Tier-0 gateways for workloads per site - To enable an active-active data plane, a stretched edge NSX-T cluster is created manually by deploying an edge appliance in each site. This action enables access to the stretched L2 NSX-T overlay segments, which host the workload VMs if a failure occurs in one of the sites. For more information, see [Multizone region data center active-active topology](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vrw-nsxt-topologiesfss-nsx-topologiest-mzraa)
* Single-zone vSAN - Regulated workloads automatically deploys management and resource clusters with stretched vSAN storage. For more information, see [Storage](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vrw-storage)).
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. The routing to IBM Cloud services uses these uplinks. IP addresses for the uplinks are provisioned by automating the 10/8 address space that is managed by the IBM Cloud.
5. 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 routing to internet uses these uplinks and 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 and expand it by adding new Tier-1 gateways.
7. You can add new tenant segments to the existing Tier-1 gateway (or to the other Tier-1 gateways provisioned by you). The route advertisements between T1 and T0 gateways is customizable by you fully and done by NSX-T. No routing protocol is required or used between T1 and T0 advertisements. You can control which routes are advertised to the Tier-0. You can also use NAT, for example each Tier-1 gateway can have one or more IP public addresses for inbound or outbound public traffic to be used for NAT.



You can deploy edge nodes on the initial cluster for scalability manually, if needed. You can also deploy new edge clusters to host new Tier-1 gateways manually.

Tier-0 gateways support VRF Lite, which can be used if needed to support more complex topologies for isolating routing tables at Tier-0 level as well. Refer to VMware® documentation for more details on capabilities and limitations.





 Multisite – single tenant 

Multisite – single tenant is also a common use case and network deployment pattern. This topology provides seamless site recovery by using dynamic routing protocols, such as BGP. The vCenter Server automation does not deploy multisite topology automatically. However, you can customize the default single-site topology post initial vCenter Server deployment.
If you want to route natively with IBM Cloud VPC subnets and other connected service without using NAT in T1, enable route advertisement of "All Connected Segments & Service Ports" in the specific T1. You must not configure a routing protocol or static routes between T1 and T0 logical routers. After enabling the route advertisement, NSX-T creates routes automatically. With this approach, you have all connected segments on your T1 routed to T0, and then you can decide how to proceed with the public and private traffic in T0.





 Public traffic between Tier-0 and VPC 

The second architectural decision to be made for your solution is public traffic. If your workloads need direct public traffic and have inbound public traffic without using any network translation, you must provision the public uplink subnet and public T0 uplink VLAN interfaces. Also, you must configure your T0 with public uplinks as described in the topic [Tier-0 logical router](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vpc-ryo-nsx-t-logical-routersvpc-ryo-nsx-t-logical-routers-edge-tier-0) previously. As the NSX-T T0 uses Active-Standby, the HA VIP provides high availability for the routing of public traffic between VPC, T0 and your NSX-T workloads. When you need public IPs, you can order floating IP address to the HA VIP VLAN interface. Each floating IP is a single /32IP address, and you can order as many as you need within [VPC Quotas](https://cloud.ibm.com/docs/vpc?topic=vpc-quotas).



Table 1. Public uplink HA VIP to be used for Public floating IPs

 Interface name Interface type VLAN ID Subnet Allow float Allow IP spoofing Enable Infra NAT NSX-T interface Segment name
The Edge Services Gateways in the NSX-V environment serve as the default gateway for all north-south traffic from the workload VMs on the Logical Switch until disconnect the NSX-V Logical Switch from the Distributed Logical Router (DLR), and connect the NSX-T overlay segment to the Tier-0 or Tier-1 gateway. This switches the default gateway to the NSX-T Tier-0 or Tier-1 gateway, depending on the chosen NSX-T topology.

After all the workloads are migrated from NSX-V to NSX-T, you can remove the bridge.





 Related links 



* [Overview of edge bridging in NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/migration/GUID-12FE83E9-2FA9-40F7-A3FF-BC21E13F6720.html)
* [Extending Layer 2 networks with NSX-T edge bridge](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/migration/GUID-5B9390FB-7E52-4669-AF63-3C3490841432.html)
* [Ordering services for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_addingservices)
* [Veeam technical documentation](https://www.veeam.com/documentation-guides-datasheets.html?ad=in-text-link)
* [Zerto product documentation](https://help.zerto.com)
* [Migration between vCenter Server systems](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vcenterhost.doc/GUID-59C7D7FF-D17E-45BC-9145-06B2993880A2.html)
For more information, see [NSX-T Data Center Multisite](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-5D7E3D43-6497-4273-99C1-77613C36AD75.html) and also [NSX-T Multi Location Design Guide](https://communities.vmware.com/t5/VMware-NSX-Documents/NSX-T-Multi-Location-Design-Guide-Federation-Multisite/ta-p/2810327?attachment-id=107432).
* Active-Active NSX-T data plane - This pattern is suitable for where the network latency between data centers is less than 10 ms, such as between availability zones in the same region. For more information, see [NSX-T Data Center Multisite](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-5D7E3D43-6497-4273-99C1-77613C36AD75.html) and also [NSX-T Multi Location Design Guide](https://communities.vmware.com/t5/VMware-NSX-Documents/NSX-T-Multi-Location-Design-Guide-Federation-Multisite/ta-p/2810327?attachment-id=107432).
* Stretched L2 capable - It is possible to do the stretching of layer 2 NSX-T overlay segments across virtual data centers.
* Single edge cluster Tier-0 gateway for workloads - The automation deploys a single NSX-T edge cluster, consisting of a pair of edge appliances, hosting an active standby Tier-0 gateway for use by the workload VMs. These VMs provide connection between the overlay and underlay networks.