vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Understanding Link endpoints and Satellite 

Open up Satellite endpoints in the Satellite control plane to control and audit network traffic between your IBM Cloud Satellite® location and services, servers, or apps that run outside of the location.

With Satellite Link endpoints, you can allow any client that runs in your Satellite location to connect to a service, server, or app that runs outside of the location, or allow a client that is connected to the IBM Cloud private network to connect to a service, server, or app that runs in your location.

To establish the connection, you must specify the destination resource's fully qualified domain name (FQDN) or IP address, port, the connection protocol, and any authentication methods in the endpoint. The endpoint is registered with the Satellite Link component of your location's Satellite control plane. To help you maintain enterprise security and audit compliance, Satellite Link additionally provides built-in controls to restrict client access to endpoints and to log and audit traffic that flows over endpoints.



 Architecture 

You can create two types of endpoints, depending on your use case: a cloud endpoint, or a location endpoint.

Cloud endpoint
: Destination resource runs outside of the Satellite location. A cloud endpoint allows you to securely connect to a service, server, or app that runs outside of the location from a client within your Satellite location.

Location endpoint
: Destination resource runs in the Satellite location. A location endpoint allows you to securely connect to a server, service, or app that runs in your Satellite location from a client that is connected to the IBM Cloud private network.

The tunnel server and the connector proxy network traffic over a secure TLS connection between cloud services and resources in your Satellite location. This Link tunnel serves as a communication path over the internet that uses the TCP protocol and port 443, and encrypts payloads via TLS. Three tunnels are created between the tunnel server in IBM Cloud and the connector in the location's control plane worker nodes. This redundancy supports the three availability zones of your location, and helps ensure communication in the case of a single zone failure. However, the three tunnels are orchestrated together so that the client that uses a Link endpoint sees a single connection.
Learning about Satellite architecture, workload isolation, and dependencies 

Learn about the IBM Cloud Satellite service architecture, its components, how your workloads are isolated from other tenants, and what other IBM Cloud and third-party services Satellite depends on.



 Satellite architecture 

The following image shows the main components in IBM Cloud Satellite and how they interact with each other.

Zoom

![Satellite for IBM Cloud service architecture](https://cloud.ibm.com/docs-content/v1/content/c8335d66af691d19e837116fd633481c477061eb/satellite//images/sat_architecture.svg)

Figure 1. Satellite service architecture

While communication from your location to some Satellite services is routed fully through the Link tunnel server, other services might require outbound connectivity from your hosts. For more information, see the [host network requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-reqs-host-network) and [host outbound connectivity requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-reqs-host-network-outbound).



 Master and worker node components 

Review a description of the main components of the Satellite location control plane, including the IBM-managed master from the IBM Cloud region and the worker nodes that you set up in your location.

Master components

Worker node components



Overview of Satellite control plane master components.
Overview of the Satellite control plane master components

 Master components Description 

 Satellite Link tunnel The Satellite Link tunnel server creates a secure TLS connection to the Satellite Link connector that runs on the control plane worker nodes in your Satellite location. Three tunnels are created between the tunnel server and the connector to support redundancy across the three availability zones of your location. All communication that leaves and enters your location is proxied by the Link tunnel server, and the connection metadata captured and monitored by IBM to detect malicious activity. To control the network connections between the workloads that run in your location and the IBM Cloud multizone metro that manages your location, you can set up Satellite Link endpoints.
Management plane <br><br> * Provides separation between your workloads and management operations.<br> * Includes a bastion host and tools like CI/CD, logging, and monitoring.<br><br><br> 
 Other application services (optional) <br><br> * Provides any other on-premises services that are needed by your workloads, such as databases and APIs.<br><br><br> 







 Next steps 



* [Satellite use cases](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-satellite-architecture-use-cases)
* [Satellite shared responsibility model](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-satellite-architecture-shared-responsibilities)
* [Satellite architecture best practices](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-satellite-architecture-best-practices)
* 10 Gbps (Gigabits per second), would be 1200 MiB/s (Mebibyte per second)







 Networking connectivity considerations 

For an overview of the connectivity options available, see [Determining access to your SAP system landscape](https://cloud.ibm.com/docs/sap?topic=sap-determine-access).

SAP Systems are often the focal point of business operations, with a great number of integrated applications (including legacy applications).

In most circumstances for SAP workloads, a connection to the existing internal network is required, and it is recommended to use IBM Cloud® Direct Link 2.0 to operate the secure, low-latency, high-throughput (available up to 10 Gbps) as a Routed OSI Layer-2/3 connection.

These connectivity options are dependent on business requirements, for example, whether the business wants to use Cloud and also decrease security risk by isolating network flows through their existing networking structure and security. In these "disconnected" or "private-only" connectivity designs, it is best to request IBM Cloud® for additional information and discuss your use cases.

In addition, it is strongly not recommended by SAP to split the SAP System tiering across On-Premises location/s and Cloud locations and it is up to the business to evaluate this; for example, it is not recommended by SAP to retain SAP AnyDB run from infrastructure in an On-Premises location and connect to SAP NetWeaver run from infrastructure in a Cloud location. For IBM Power Systems Virtual Servers this split of SAP System tiering is not supported.



 Bring-your-own network (Subnet/CIDR/IP address range) 

It is often a business preference to Bring-your-own Subnet/CIDR/IP address range (BYOIP) to your IBM Cloud account; this is available depending on the Infrastructure selection and environment.



 VPC Infrastructure 

When using VPC Infrastructure, it is possible to define and use your own subnet. See [VPC - Bring your own subnet](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes).
This routing is done at the router that the VRA is behind, which is the Frontend Customer Router (FCR) or the Backend Customer Router (BCR) for public and private traffic respectively.

Be aware that VRRP is disabled by default, and it must be enabled in order for VLAN traffic to work, even on stand-alone Vyattas. This is a consequence of the subnets on the associated VLAN's being routed to the VRRP IP or virtual-address assigned to the VRA. For more information, see [VRRP virtual IP (VIP) addresses](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-working-with-high-availability-and-vrrpvrrp-virtual-ip-vip-addresses).

Servers in an associated VLAN can only be reached from other VLANs by going through your IBM Cloud® Virtual Router Appliance; it is not possible to circumvent the VRA unless you bypass or disassociate the VLAN.

By default, a new gateway appliance is associated with two non-removable "transit" VLANs, one each for public and private. These are typically used for administration and can be separately secured by VRA commands.

Transit VLANs are for network devices like firewalls or load balancers so that they can route traffic while keeping other devices, such as servers or containers, isolated from the internet. In comparison, "gateway" VLANs are where devices, such as servers and containers, are hosted.

The VRA can manage only VLANs that are associated with it through the gateway appliance.

For more information, see [Managing VLANs with a gateway appliance](https://cloud.ibm.com/docs/virtual-router-appliance?topic=gateway-appliance-managing-vlans-and-gateway-appliances).
If you don't have an SSH key, follow [the instructions](https://cloud.ibm.com/docs/vpc?topic=vpc-ssh-keys) for creating a key for VPC.



See the [prerequisites](https://github.com/IBM-Cloud/vpc-transitprerequisites) for a few options including a Dockerfile to easily create the prerequisite environment.

In addition:



* Check for user permissions. Be sure that your user account has sufficient permissions to create and manage all the resources in this tutorial. See the list of:



* [required permissions for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-user-permissions-for-vpc-resources).
* [required permissions for creating Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-iam).
* [required permissions for IP spoofing checks](https://cloud.ibm.com/docs/vpc?topic=vpc-ip-spoofing-about).









 Summary of Part one 

In [part one](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-transit1) of this tutorial we carefully planned the address space of the transit and spoke VPCs. The zone based architecture is shown below:

Zoom

![Zones](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/includes/solution-tutorials/includes/solution-tutorials/images/vpc-transit/vpc-transit-zones.svg)

Zones

This diagram shows the traffic flow. Only the enterprise <-> spoke is passing through the firewall:

Zoom

!
This approach is not recommended in IBM Cloud between two vCenter Server instances for V2T migration as NSX-T L2 Bridge offers better performance. And also because IBM Cloud private network supports large MTU (jumbo frames).





 Related links 



* [Terraform by Hashicorp](https://www.terraform.io/)
* [The NSX Terraform Provider](https://registry.terraform.io/providers/vmware/nsxt/latest/docs)
* [NSX-V to NSX-T 3.x Migration Coordinator](https://nsx.techzone.vmware.com/resource/nsx-v-nsx-t-3x-migration-coordinator_Toc57645169)
* [NSX-V to NSX-T fast track migration service](https://hdm.primaryio.com/lp/nsxvtot)
* [HDM Cloud Connect NSX-V to NSX-T](https://cloud.ibm.com/catalog/services/hdm-cloud-connect-nsx-v-to-nsx-tabout)
Route description Device CIDR Next-hop 

 Default route T0 Logical Router 0.0.0.0/0 Default GW of 







 Private traffic between Tier-0 and VPC 

The third architectural decision to be made for your solution is private traffic. Routing between T1 and T0 was discussed previously, and this approach assumes that your T0 knows how to reach the IP subnets/prefixes configured for the segments that are attached to either T1 and T0.

If you have both Public and Private Uplinks, the first step is to create a route in NSX-T T0 pointing to the Private networks you must connect to from the VMware workloads that are attached to NSX-T overlay segments. These networks must be reachable through the VPC, or DL/TGW to which the VPC is attached to. The following table shows an example, when private prefix 172.16.0.0/16 is used elsewhere and this prefix is known by VPC, either directly or through attached Direct Link (DL) or Transit Gateway (TGW).



Table 6. Private routes in T0 Logical Router with Public Uplinks

 Route description Device CIDR Next-hop 

 Private networks T0 Logical Router 172.16.0.0/16 Default GW of vpc-t0-private-uplink-subnet 



If you use only private route, then your default route 0.0.0.0/0 in NSX-T T0 Logical Router routes all traffic to the VPC.

You must define inbound traffic from VPC. Then, you must create a VPC route in the Zone to the IP subnet or prefix that you are using in the NSX-T overlay. As the NSX-T T0 uses Active-Standby, the HA VIP provides high availability for the routing of private traffic between VPC and your NSX-T overlay. Therefore, the next-hop for the VPC route must be the HA VIP, as specified on the following table.



Table 7. 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
If you don't have an SSH key, follow [the instructions](https://cloud.ibm.com/docs/vpc?topic=vpc-ssh-keys) for creating a key for VPC.



See the [prerequisites](https://github.com/IBM-Cloud/vpc-transitprerequisites) for a few options including a Dockerfile to easily create the prerequisite environment.

In addition:



* Check for user permissions. Be sure that your user account has sufficient permissions to create and manage all the resources in this tutorial. See the list of:



* [required permissions for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-user-permissions-for-vpc-resources).
* [required permissions for creating Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-iam).
* [required permissions for IP spoofing checks](https://cloud.ibm.com/docs/vpc?topic=vpc-ip-spoofing-about).









 Summary of Part one 

In [part one](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-transit1) of this tutorial we carefully planned the address space of the transit and spoke VPCs. The zone based architecture is shown below:

Zoom

![Zones](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/vpc-transit/vpc-transit-zones.svg)

Zones

This diagram shows the traffic flow. Only the enterprise <-> spoke is passing through the firewall:

Zoom

!
Therefore, in this deployment topology, a gateway appliance and GRE tunnels are used to provide connectivity.

This topology focuses on Direct Link (2.0) service that has the following offerings:



* Direct Link Dedicated - A single-tenant, fiber-based, cross-connect into the IBM Cloud Private network.
* Direct Link Connect - Uses a service provider who is already connected to the IBM Cloud Private network to deliver multi-tenant, high capacity links, also known as network-to-network interfaces.



Currently, Direct Link (2.0) is not available in all locations. For more information, see [Locations and providers](https://cloud.ibm.com/docs/dl?topic=dl-locations).

If Direct Link (2.0) is not available at a suitable location, then see [Getting started with IBM Cloud Direct Link on Classic](https://cloud.ibm.com/docs/direct-link?topic=direct-link-get-started-with-ibm-cloud-direct-link).

Zoom

![Direct Link on Classic deployment scenario](https://cloud.ibm.com/docs-content/v1/content/1d36273917990fbf48078805e201d2e85e2fcb27/power-iaas/images/network-dl-gre.svg)

Figure 7. Direct Link on Classic deployment scenario

This deployment topology leverages the IBM Cloud classic infrastructure gateway appliance to provide a GRE gateway. For more information, see [Getting started with IBM Cloud Gateway Appliance](https://cloud.ibm.com/docs/gateway-appliance?topic=gateway-appliance-getting-started). - The IBM Cloud gateway appliance allows you to selectively route private and, optionally, public network traffic through a full-featured, enterprise-level firewall that is powered by the software features of; VyOS, JunOS, or any other operating system (Bring Your Own Appliance) you choose. - All appliance features are customer-managed.
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.

The NSX-V logical switch (virtual wire) to be bridged requires MAC Learning or promiscuous mode and Forged Transmit to be enabled as the Edge Node VM must be able to send and receive traffic with different MAC address than its own. See [Configure the Logical Switch to Connect to the Edge Bridge](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/migration/GUID-206CF244-3171-4146-9C60-43A797B15043.html).

VMware® uses the same MAC address for the NSX-V DLR and the NSX-T distributed router and an API call to NSX-T Manager is required to change the MAC address of the NSX-T distributed router to avoid overlap with the NSX-V DLR when bridging. 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 management NIC on the NSX-T Edge node VM must be able to reach the NSX-T Managers. The tunnel NIC (TEP) must have connectivity to the other NSX-T transport nodes, while the third NIC is connected directly to the NSX-V logical switch (virtual wire) to be bridged.





 Related links
Default route T0 Logical Router 0.0.0.0/0 Default GW of vpc-t0-private-uplink-subnet 







 Private traffic between Tier-0 and VPC 

The third architectural decision to be made for your solution is private traffic. Routing between T1 and T0 was discussed previously, and this approach assumes that your T0 knows how to reach the IP subnets/prefixes configured for the segments that are attached to either T1 and T0.

If you have both Public and Private Uplinks, first thing is to create a route in NSX-T T0 pointing to the Private networks that you must connect to the VMware workloads attached to NSX-T overlay segments. These networks must then be reachable through the VPC, or DL/TGW to which the VPC is attached to. The following table shows an example, when private prefix 172.16.0.0/16 is used elsewhere and this prefix is known by VPC, either directly or through attached Direct Link (DL) or Transit Gateway (TGW).



Table 4. Private routes in T0 Logical Router with Public Uplinks

 Route description Device CIDR Next-hop 

 Private networks T0 Logical Router 172.16.0.0/16 Default GW of vpc-t0-private-uplink-subnet 



If you use only private route, then your default route 0.0.0.0/0 in NSX-T T0 Logical Router routes all traffic to the VPC.

You must define inbound traffic from VPC. Then, you must create a VPC route in the Zone to the IP subnet/prefix that you are using in the NSX-T overlay. As the NSX-T T0 uses Active-Standby, the HA VIP provides high availability for the routing of private traffic between VPC and your NSX-T overlay. Therefore, the next-hop for the VPC route must be the HA VIP, as specified on the following table.



Table 5. 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
remote_tunnel_ip <br>Optional <br>Forces new resource <br>string The remote tunnel IP address. This field only applies to gre_tunnel and unbound_gre_tunnel type connections. 
 zone <br>Optional <br>Forces new resource <br>string The location of the GRE tunnel. This field only applies to gre_tunnel and unbound_gre_tunnel type connections. 





 Example 

This example illusstrates creating a transit gateway connection using Terraform:

resource "ibm_tg_connection" "test_ibm_tg_connection" {
gateway = ibm_tg_gateway.test_tg_gateway.id
network_type = "vpc"
name = "myconnection"
network_id = ibm_is_vpc.test_tg_vpc.resource_crn
}
Architecture pattern for single site NSX-T topologies 

VMware vCenter Server® instances offer a standard VMware NSX-T™ topology with a single NSX-T edge cluster, which includes Tier-0 (T0) and Tier-1 (T1) Gateways. You have several options to build and customize the overlay topology. You can provision new NSX-T edge clusters and deploy new Tier-0 (T0) and Tier-1 (T1) Gateways.

This pattern provides a few examples on how these topologies can be customized for your needs.



 Single-site – single tenant 

Single-site – single tenant is the most common use case and network deployment pattern. The vCenter Server automation deploys an example topology by following this model, which includes single Tier-0 and Tier-1 Gateways and a few NSX-T overlay segments as a starting point. This topology is highly scalable and easy to automate.

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.
* [IBM Cloud® Direct Link for communication over the private network with resources in on-premises data centers](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsworker-services-onprem-direct-link)
* [strongSwan IPSec VPN connection for communication over the public network with resources in on-premises data centers](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsworker-services-onprem-strongswan)



* [External communication to apps that run on worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsexternal-workers)



* [Private traffic to cluster apps](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsexternal-workers-private)
* [Public traffic to cluster apps](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsexternal-workers-public)



* [Scenario: Running internet-facing app workloads in a classic cluster](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsinternet-facing)



* [Worker-to-worker communication in classic clusters with internet-facing workloads](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsinternet-facing-worker)
* [Worker-to-master and user-to-master communication in classic clusters with internet-facing workloads](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsinternet-facing-master)
* [Worker communication to other services or networks with internet-facing workloads](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsinternet-facing-services)
* [External communication to apps that run on worker nodes with internet-facing workloads](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsinternet-facing-external)