vania-janet/multiturn-rag-retrieval-data huggingface dataset:
See [Getting started with IBM Cloud Direct Link (2.0)](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl), however, key elements of IBM Cloud Direct Link (2.0) include the following:



* Requires BGP to establish the routes to a customer's remote network.
* Each IBM Cloud Direct Link service is not redundant, however, diversity can be enabled over multiple Direct Links along with BGP.
* Ensure that IP subnet overlaps do not exist between the infrastructure environments and the remote networks.



6. Configure a GRE tunnel between the gateway appliance and a tunnel endpoint that is connected to your external network to enable the remote network connectivity. For more information, see [Configuring Generic Routing Encapsulation (GRE) tunnel](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-cloud-connectionsconfigure-gre-tunnel).



For tutorials based on some of the topologies described, see [IBM Power Virtual Server Virtual Private Network Connectivity](https://cloud.ibm.com/media/docs/downloads/power-iaas-tutorials/PowerVS_VPN_Tutorial_v1.pdf).





 Connecting two Power Systems Virtual Server environments by using IBM Cloud Transit Gateway 

In this deployment topology, a connection through IBM Cloud Transit Gateway is used to provide connectivity between Power virtual server environments located at two different data centers. With IBM Cloud Transit Gateway, you can also interconnect your Power Systems Virtual Servers to the IBM Cloud classic and VPC infrastructures, keeping traffic within the IBM Cloud network. Transit Gateway enables you to connect your otherwise disconnected private networks, such as classic, VPC, and Direct Link. In addition, you can establish connection between multiple Power Systems Virtual Server workspaces across different data centers.

The following network architecture allows connectivity between multiple Power Systems Virtual Server locations with high availability (HA) and disaster recovery (DR) solutions.

Zoom

!
Figure 1. Transit Gateway with vCenter Server and NSX-T

The following list summarizes the architecture pattern deployment:



1. vCenter Server instance is deployed at IBM Cloud Classic Infrastructure. Two IBM Cloud private VLANs and one IBM Cloud Public VLAN (optional) is deployed. Each of them hosts multiple subnets. You can see the details through IBM Cloud for VMware Solutions portal.
2. NSX-T T0 is deployed with two interfaces - private and public (optional). If you opt for a public, this interface is attached to your Public VLAN and has direct internet access. Your T0 private interface is attached to the Private VLAN and it is using IBM Cloud Portable Private IP.
3. vSRX (or other device) running on the gateway cluster or gateway appliance is deployed to your Classic Infrastructure. Configure your vCenter Server instance private primary VLAN to be routed through the vSRX or Gateway Appliance. Also, establish routing between your NSX-T T0 and vSRX, such as BGP.
4. Order an IBM Cloud Transit Gateway at your IBM Cloud data center or zone location and [add your classic network as a connection](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-adding-connections).
5. [Create a GRE connection on your transit gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-GRE-connection) by using your classic network as the transport for your GRE tunnel. For the remote gateway IP, select your vSRX or gateway appliance private IP. For the Local gateway IP, you can select an IP address to be advertised through your Classic Network to the vSRX or Gateway Appliance. Ensure that your vSRX or Gateway Appliance has a route to this IP. For Local or Remote tunnel IP, you can select the IP addresses for the GRE tunnel IP addresses.
6. Your vSRX or Edge Gateway Appliance and Transit Gateway must exchange routes through BGP.
Your primary public VLAN uplinks are attached to an untagged VLAN segment (VLAN 0), and a matching VLAN backed segment (for the default setup, VLAN 0 is used) is created for the public uplinks.







 Considerations 

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



* Refer to the specific third-party vendor hardware and software specifications for interoperability with VMware® ESXi™ and NSX-T™.
* You must provide licensing (BYOL) for the third-party router or firewall solution. Contact your vendor for details.







 Related links 



* [VMware vSphere overview](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vs_vsphereclusteroverview)
* [Getting started with IBM Cloud Gateway Appliance](https://cloud.ibm.com/docs/gateway-appliance?topic=gateway-appliance-getting-started)
* [Tier-0 Gateways](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-E9E62E02-C226-457D-B3A6-FE71E45628F7.html)
This gateway acts as the public entry point to your apps and uses the existing istio-ingressgateway load balancer service to expose your app. The gateway can optionally be configured for TLS termination.
* A virtual service called my-virtual-service. my-gateway uses the rules that you define in my-virtual-service to route traffic to your app.
* A subdomain for the istio-ingressgateway load balancer. All user requests to the subdomain are forwarded to your app according to your my-virtual-service routing rules.





 Exposing the Istio ingress gateway with DNS without TLS termination 



1. [Install the istio managed add-on](https://cloud.ibm.com/docs/containers?topic=containers-istioistio_install) in a cluster.
2. [Install the istioctl CLI](https://cloud.ibm.com/docs/containers?topic=containers-istioistioctl).
3. [Set up sidecar injection for your app microservices, deploy the app microservices into a namespace, and create Kubernetes services for the app microservices so that they are in the Istio service mesh](https://cloud.ibm.com/docs/containers?topic=containers-istio-meshistio_sidecar).



To publicly expose apps:



1. Create a gateway that uses the public istio-ingressgateway load balancer service to expose port 80 for HTTP. Replace <namespace> with the namespace where your Istio-managed microservices are deployed. For more information about gateway YAML components, see the [Istio reference documentation](https://istio.io/latest/docs/reference/config/networking/gateway/).

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-gateway
spec:
selector:
app: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
[Direct Link with NSX-T and EVPN](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-vcs-nsx-t-direct-link-evpn.svg)

Figure 1. Direct Link with NSX-T and EVPN

This architecture pattern deployment is summarized as follows:



1. vCenter Server instance is deployed at IBM Cloud classic infrastructure. Two IBM Cloud private VLANs and one IBM Cloud Public VLAN (optional) are deployed. Each of these VLANs host multiple subnets. You can see the details through IBM Cloud for VMware Solutions portal.
2. NSX-T T0 is deployed with two interfaces - private and public (optional). If you opt for a public one, this interface is attached to your Public VLAN and has direct internet access. Your T0's private interface is attached to the Private VLAN and it uses IBM Cloud portable private IP.
3. 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. Ensure that you allow BGP and VXLAN traffic though the firewall.
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). Ensure that you advertise the required networks for establishing the BGP session and VXLAN traffic.
5. Configure MP-BGP with eBGP multihop and EVPN on your T0 router. Create a T0 VRF for each tenant as an EVPN tenant in NSX-T.
6. VXLAN or VNI is used for each tenant.
"network_account_id": "28e4d90ac7504be694471ee66e70d0d5",
"prefix_filters": [
{
"action": "permit",
"before": "1a15dcab-7e40-45e1-b7c5-bc690eaa9782",
"created_at": "2022-02-18T16:51:50.748Z",
"ge": 0,
"id": "1a15dcab-7e30-45e1-b7c5-bc690eaa9865",
"le": 32,
"prefix": "192.168.100.0/24",
"updated_at": "2022-02-18T16:51:50.748Z"
}
],
"prefix_filters_default": "permit",
"remote_bgp_asn": 65010,
"remote_gateway_ip": "10.242.63.12",
"remote_tunnel_ip": "192.168.129.1",
"request_status": "pending",
"status": "attached",
"updated_at": "2022-02-18T16:51:50.748Z",
"zone": {
"name": "us-south-1"
}
}

For more information (including Java, Node, Python and Go examples), see "Add Connection to a Transit Gateway" in the [Transit Gateway API reference](https://cloud.ibm.com/apidocs/transit-gateway?code=javacreate-transit-gateway-connection).









 Adding a connection using Terraform 

Review the following argument references that you can specify for your resource when creating a connection for a transit gateway using Terraform:



Table 5. Terraform argument references for creating a connection

 Argument Details
Interface name Interface type VLAN ID Subnet Allow float VMkernel adapter Distributed Port Group name 

 vlan-nic-tep-vmk10 vlan 400 vpc-tep-subnet false vmk10 dpg-tep 



Host TEP VLAN ID is defined in the host transport profile. The dpg-tep creation is optional, and for consistency only. It might help you to identify the VLAN ID used when operating the environment later.





 Edge transport nodes and gateway cluster 

In addition to NSX Managers, NSX-T gateway cluster and NSX Edge Nodes are required in an NSX-T deployment. The Edge Nodes are specific service appliances that are dedicated to running centralized network services. They cannot be distributed to the ESXi hypervisors, such as Network Address Translation or north-south traffic between NSX-T Geneve Segments and VPC subnets. NSX Edge Nodes are transport nodes that run local control plane daemons and forwarding engines that implement the NSX-T data plane.

VM form factor Edge Nodes are used in this architecture. Edge Nodes can be grouped in one or several clusters, representing a pool of capacity. NSX-T Logical Routers, Tier-0 (also referred as T0) and Tier-1 (also referred as T1) can be hosted in the same or different gateway clusters. Also, in this architecture, a single gateway cluster is created for all T0 and T1 Logical Routers. A T0 Logical Router provides north-south connectivity and connects to a VPC subnet. A T1 logical router connects to one T0 logical router, and it provides northbound connectivity to the NSX-T segments attached to it.

The following table summarizes the requirements for a Medium Form Factor Edge environment, which is the recommended starting size for production workloads.



Table 4. NSX-T Edge Node specifications

 Attribute Medium Edge Node 

 NSX Edges 2 VMs 
 Number of vCPUs 4 
 Memory 8 GB 
 Disk 200 GB 
 Network: Management vpc-mgmt-subnet 



As for the other NSX-T components, VLAN interfaces must be created in IBM Cloud VPC for connectivity.
[Expose an app in a single-zone cluster by using Ingress](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift//images/roks_router_ingress_single.png)

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



1. A user sends a request to your app by accessing your app's URL. This URL is the Ingress subdomain for your cluster appended with the Ingress resource path for your exposed app, such as mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.
2. A DNS system service resolves the subdomain in the URL to the portable public IP address of the load balancer that exposes the Ingress controller in your cluster.
3. Based on the resolved IP address, the client sends the request to the Ingress controller service.
4. The Ingress controller checks the routing rules that are implemented by the Ingress controller for a routing rule for the myapp path. If a matching rule is found, the request is proxied according to the rules that you defined in the Ingress controller and the Route resource to the pod where the app is deployed. The source IP address of the packet is changed to the IP address of the worker node where the Ingress controller pod runs. If multiple app instances are deployed in the cluster, the Ingress controller load balances the requests between the app pods.
5. When the app returns a response packet, it uses the IP address of the worker node where the Ingress controller that forwarded the request exists. The Ingress controller then sends the response packet to the client.







 Multizone cluster 

The following diagram shows how Ingress directs communication from the internet to an app in a classic multizone cluster.

Zoom

!
The NLB serves as the external entry point for incoming requests for the app. To access the NLB from the internet, you can use the public IP address of your NLB and the assigned port in the format <IP_address>:<port>. You can also create DNS entries for NLBs by registering the NLB IP addresses with subdomains.

When you expose an app with an NLB service, your app is automatically made available over the service's NodePorts too. [NodePorts](https://cloud.ibm.com/docs/containers?topic=containers-nodeport) are accessible on every public and private IP address of every worker node within the cluster. To block traffic to NodePorts while you are using an NLB, see [Controlling inbound traffic to network load balancer (NLB) or NodePort services](https://cloud.ibm.com/docs/containers?topic=containers-network_policiesblock_ingress).

Kubernetes 1.20 and later: Although the Kubernetes [SCTP protocol](https://kubernetes.io/docs/concepts/services-networking/service/sctp) is generally available in the Kubernetes community release, creating load balancers that use this protocol is not supported in IBM Cloud Kubernetes Service clusters.



 Comparison of basic and DSR load balancing in version 1.0 and 2.0 NLBs 

When you create an NLB, you can choose a version 1.0 NLB, which performs basic load balancing, or version 2.0 NLB, which performs direct server return (DSR) load balancing.

How are versions 1.0 and 2.0 NLBs similar?
: Version 1.0 and 2.0 NLBs are both Layer 4 load balancers that exist in the Linux kernel space. Both versions run inside the cluster, and use worker node resources. Therefore, the available capacity of the NLBs is always dedicated to your own cluster. Additionally, both versions of NLBs don't terminate the connection. Instead, they forward connections to an app pod.

How are versions 1.0 and 2.0 NLBs different?
See also [organization](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2032585).





 SSH 

See [Secure Shell](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx3574365).





 SSL 

See [Secure Sockets Layer](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2038004).





 SSO 

See [single sign-on](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2213318).





 stage 

To deploy an application, service, or instance to a pre-defined location for running or testing before deployment to a production environment. See also [deployment](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2104544).





 stanza 

A section of a software package that defines either a specific action to be performed on that the software package or a set of conditions under which actions are to be performed on the software package. The complete software package is a stanza that contains a hierarchy of many different stanzas.





 state database 

A database that contains the current values for all keys on a blockchain ledger for a channel.





 subdomain 

A domain that makes up a part of a larger domain. See also [host](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2002243), [Uniform Resource Locator](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2042491), [custom domain](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx5728384), [domain](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2021210), [route](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2037338).





 subject
* [Exposing the Istio ingress gateway with DNS without TLS termination](https://cloud.ibm.com/docs/containers?topic=containers-istio-meshistio-no-tls)
* [Exposing the Istio ingress gateway with DNS with TLS termination](https://cloud.ibm.com/docs/containers?topic=containers-istio-meshistio_tls)



* [Securing in-cluster traffic by enabling mTLS](https://cloud.ibm.com/docs/containers?topic=containers-istio-meshmtls)



[Deploying custom Istio gateways](https://cloud.ibm.com/docs/containers?topic=containers-istio-custom-gatewayistio-custom-gateway)



* [Considerations](https://cloud.ibm.com/docs/containers?topic=containers-istio-custom-gatewayconsiderations)
* [Creating a custom ingress gateway for public traffic](https://cloud.ibm.com/docs/containers?topic=containers-istio-custom-gatewaycustom-ingress-gateway-public)



* [Set up the BookInfo sample](https://cloud.ibm.com/docs/containers?topic=containers-istio-custom-gatewaycustom-gateway-bookinfo)
* [Exposing BookInfo by using an IBM-provided subdomain with TLS](https://cloud.ibm.com/docs/containers?topic=containers-istio-custom-gatewaycustom-gateway-bookinfo-dns)



* [Creating a custom ingress gateway for private network traffic](https://cloud.ibm.com/docs/containers?topic=containers-istio-custom-gatewaycustom-ingress-gateway-private)
* [Controlling custom gateway updates and versions](https://cloud.ibm.com/docs/containers?topic=containers-istio-custom-gatewaycustom-gateway-version)
[Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/d4c3786f8c60e7b8960682eaca5d28a1d2d8a237/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/d4c3786f8c60e7b8960682eaca5d28a1d2d8a237/icons/checkmark-icon.svg) 
 Open VPN Termination ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/d4c3786f8c60e7b8960682eaca5d28a1d2d8a237/icons/checkmark-icon.svg) Only with single port on TCP/UDP 
 HA Option N/A ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/d4c3786f8c60e7b8960682eaca5d28a1d2d8a237/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/d4c3786f8c60e7b8960682eaca5d28a1d2d8a237/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/d4c3786f8c60e7b8960682eaca5d28a1d2d8a237/icons/checkmark-icon.svg) !
The automation deploys and configures the vCenter appliances.
* Dual vCenters - Each site has a vCenter deployed automatically. However, they are not linked.
* Single NSX-T Manager cluster - The automation deploys three NSX-T Manager appliances in a cluster with a Virtual IP address.
* Dual NSX-T Manager clusters - Each site has its own NSX-T Manager cluster that is deployed automatically, which is independent of each other. In NSX-T, it doesn't exist a concept equivalent to Cross-vCenter NSX-V.
* Active NSX-T data plane - All site ingress and egress traffic traverses through the single edge cluster that is deployed in that site automatically.
* No stretched L2 capability - The stretching of layer 2 NSX-T overlay segments across sites cannot be done.
* Single edge gateway - Each virtual data center uses an active-standby edge gateway for external access to the public network or the services network. This gateway includes features such as NAT, IPsec VPN, and load balancing.
* 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. For more information, see [Single-site - single-tenant](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-v2t-example-overlaysv2t-example-overlays-single-site-st) and [Single-site - multitenant](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-v2t-example-overlaysv2t-example-overlays-single-site-mt).
* Single-zone NFS storage - vSphere data stores that use IBM Cloud file storage of different IOPs ratings are available and deployed automatically. IBM Cloud file storage can be accessed only from hosts in the same site as the vSphere hosts.
[Distributed switch design Public](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/nsx-t-3-ra-diagrams-v7-vds-public.svg)

Figure 3. NSX-T Distributed switch design Public

As shown in the previous diagrams, the public VDS instancename-clustername-public is configured for public network connectivity and the public VDS instancename-clustername-private is configured for private network connectivity. Separating different types of traffic is required to reduce contention and latency and increase security.

VLANs are used to segment physical network functions. This design uses three VLANs: two for private network traffic and one for public network traffic. The following table shows the traffic separation.



Table 5. VLAN mapping to traffic types

 VLAN Designation Traffic type 

 VLAN 1 Private A ESXi management, management, Geneve (TEP), edge uplinks 
 VLAN 2 Private B vSAN, NFS, and vMotion 
 VLAN 3 Public Available for internet access 



For the optional two host gateway clusters, this design uses two VLANs: one for private network traffic and one for public network traffic. This cluster type uses local disks as data store. Therefore, you don't need separate storage traffic. Also, according to the design, the NSX-T Geneve (TEP) traffic is left out. The following table shows the traffic separation between VLANs for this cluster type.



Table 6. VLAN mapping to Gateway traffic types

 VLAN Designation Traffic type 

 VLAN 1 Private Transit Private transit VLAN, ESXi management, and vMotion 
 VLAN 2 Public Transit Public transit VLAN 







 Naming conventions 

The following naming conventions are used for deployment. For readability, only the specific naming is used. For example, instancename-dcname-clustername-tz-edge-private is referred to as tz-edge-private.



Table 7. NSX-T design naming convention

 Description Naming Standard
The private network also contains the management Intelligent Platform Management Interface (IPMI) traffic to the physical servers.

The following figure uses these acronyms:



* BBR - Backbone Router
* BCR - Backend Customer Router
* CBS - Core Backbone Switch
* DAR - Distribution Aggregation Router
* FCR - Frontend Customer Router
* LBR - Load Balancer Router
* MSR - Master Service Router
* POPs - Points of Presence
* PPR - Pod to Pod Router
* SLR - Service Layer Router



Zoom

![IBM Cloud high–level network](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/vcsv4radiagrams-ra-ibmcloudnetwork.svg)

Figure 2. IBM Cloud high–level network



 Public network 

IBM Cloud data centers and network points of presence (PoPs) have multiple 1 Gbps or 10-Gbps connections to the top-tier transit and peering network carriers. Network traffic from anywhere in the world connects to the closest network PoP, and travels directly across the network to its data center, minimizing the number of network hops and handoffs between providers.

Inside the data center, IBM Cloud provides 1 Gbps, 10 Gbps, or 25 Gbps of network bandwidth to individual servers through a pair of separate, peer-aggregated front-end customer switches (FCS). These aggregated switches are attached to a pair of separate routers, FCR, for L3 networking.

This multitier design allows the network to scale across racks, rows, and pods within an IBM Cloud data center.





 Private network 

All IBM Cloud data centers and PoPs are connected by the private network backbone. This private network is separate from the public network, and it enables connectivity to services in IBM Cloud data centers around the world. Moving data between IBM Cloud data centers is done through multiple 10 Gbps or 40 Gbps connections to the private network.