vania-janet/multiturn-rag-retrieval-data huggingface dataset:
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. For more information about the Satellite Link components, see the [Satellite architecture](https://cloud.ibm.com/docs/satellite?topic=satellite-service-architecturearchitecture).



 Cloud endpoint 

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

Zoom

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

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



1. When you create an endpoint for your destination resource, a port is opened for the Satellite Link connector on your Satellite control plane worker nodes. 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.
The companion [GitHub Repository](https://github.com/IBM-Cloud/vpc-transit) has the source files to implement the architecture. In a desktop shell clone the repository:

git clone https://github.com/IBM-Cloud/vpc-transit
cd vpc-transit
2. The config_tf directory contains configuration variables that you are required to configure.

cp config_tf/template.terraform.tfvars config_tf/terraform.tfvars
3. Edit config_tf/terraform.tfvars.



* Make the required changes.
* Change the value all_firwewall = true.
* Change the value enterprise_phantom_address_prefixes_in_transit = false.



4. If you don't already have one, obtain a [Platform API key](https://cloud.ibm.com/iam/apikeys) and export the API key for use by Terraform:

export IBMCLOUD_API_KEY=YourAPIKEy
5. Since it is important that each layer is installed in the correct order and some steps in this tutorial will install multiple layers a shell command ./apply.sh is provided. The following will display help:

./apply.sh
6. You could apply all of the layers configured by executing ./apply.sh : :. The colons are shorthand for first (or config_tf) and last (vpe_dns_forwarding_rules_tf). The -p prints the layers:

./apply.sh -p : :
7. Apply all of the layers in part one and described above.

./apply.sh : spokes_egress_tf



If you were following along in part one some additional ingress routes were added to the transit ingress route table to avoid routing through the firewall-router.
* UI
* CLI
* API







 Generating a route report 

You can request a report of all routes known to a transit gateway and each of its connections. The report shows Border Gateway Protocol (BGP) information associated with these routes, which connections supply which routes, and overlapping routes.

You can retrieve a route report by using the UI, CLI, or API.



 Route report considerations 



* Overlapping routes are a common issue when configuring a transit gateway. If the routes from two or more connections overlap, traffic might not be routed as intended. For more information, see [Addressing route conflicts](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-route-reports&interface=uiroute-conflicts).
* After a new virtual connection (VPC, Classic infrastructure, or Direct Link) reaches Active state, allow 5 minutes for the routes to be learned by your transit gateway. Generating a route report before all routes are learned results in a partial route report.
* If a connection exposes a route of 0.0.0.0/0, that route is ignored when computing overlapping prefixes.
* Only one report per gateway is available at any time. If you generate a new report, the old report is deleted.
* Older route reports might be inaccurate after you add or remove a connection. As a result, if you update routes within those connections, it is recommended that you generate a new route report.







 Generating and viewing a route report in the UI 

A route report generates data for both the Routes and BGP tables in the respective views. Both of these tables allow you to generate, delete, and download the same report.

To generate a route report in the UI, follow these steps:



1. From your browser, open the [IBM Cloud console](https://cloud.ibm.com/login) and log in to your account.
2. Select the Navigation Menu ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) from the upper left, then click Interconnectivity > Transit Gateway.
3.
The diagram uses transit-.databases.appdomain.cloud to identify the database in the transit instead of the fully qualified name like 5c60b3e4-1920-48a3-8e7b-98d5edc6c38a.c7e0lq3d0hm8lbg600bg.private.databases.appdomain.cloud.
3. Apply the vpe_dns_forwarding_rules_tf layer:

./apply.sh vpe_dns_forwarding_rules_tf
4. Verify that all VPEs can be accessed from all test instances.

Your expected results are: enterprise -> spoke vpe tests will be FAILED:

pytest -m 'vpe or vpedns'



It can take a few tries for the DNS names to be resolved accurately. So try the test at least three times. All tests should pass except the enterprise to spoke VPE tests:





 Step 5: Enterprise to Spoke Virtual Private Endpoint Gateways 

The current configuration does not support enterprise -> spoke VPE traffic. The VPE return traffic does not use spoke egress route table.

It is possible to improve the results by adding the enterprise address prefixes to the transit VPC. This will allow the spoke VPE return traffic to learn the enterprise routes and forward traffic through the through the Transit Gateway to the transit VPC. However, it will be delivered to the transit VPC zone of the matching address prefix. Enterprise -> spoke cross zone will not work.

The enterprise DNS resolution must resolve the fully qualified name to the IP address of the VPE to the zone it has been assigned in the transit VPC. Configuring this is beyond the scope of this tutorial.



1. Edit config_tf/terraform.tfvars.



* Change the value enterprise_phantom_address_prefixes_in_transit = true.



2. Configuration changes require all current layers to be re-applied

./apply.sh : :
3. Verify that all VPEs can be accessed from all test instances.
NSX-V to NSX-T migration overview 

This documentation provides a validated approach and guidance for existing IBM Cloud® for VMware Solutions customers with VMware vCenter Server® with NSX-V instances. In that way, they can move and migrate their workloads to new vCenter Server with NSX-T™ instances (also referred as V2T migration). This documentation is not primarily aimed at customers that want to migrate on-premises workloads to IBM Cloud, although some of the approach and guidance is applicable.

While VMware documentation describes a number of migration approaches, only the coexist or lift-and-shift approaches are validated by IBM Cloud. In the co-exist approach, NSX-V, and NSX-T are run side by side and new workloads are placed on the new NSX-T environment and old workloads are decommissioned on the NSX-V environment. When the NSX-V environment is empty, it can be de-provisioned. This approach is not discussed further in the documentation, but it can be a validated option if you want to follow this path.

In the lift-and-shift approach, the IBM Cloud automation is used to deploy a new vCenter Server instance on the same or different VLANs. With this action, you can perform both NSX-V to NSX-T migration and workload migration.

The lift-and-shift migration approach enables:



* Flexibility to plan the migration based on your workload requirements.
* You to adopt a modular migration approach, for example, partial subnet evacuation.
* You to configure a different network topology in the NSX-T environment.
* Fail-back of a migration wave, as the existing NSX-V environment is still running.
* Over time, you can gradually migrate specific parts of the NSX-V workloads.
* Logically extending networks between both environments and move the workloads gradually from NSX-V to NSX-T.



The journey from NSX-V to NSX-T requires careful planning and preparation. You must be familiar with NSX-T concepts and administration tasks before any migrations. This journey must involve the following steps:
* Select Global routing to allow your transit gateway to connect to VPC resources in all IBM [Multi-Zone Regions (MZRs)](https://cloud.ibm.com/docs/overview?topic=overview-locationsmzr-table).



You can upgrade routing options at a later point if your needs change. Pricing is changed accordingly.
6. Choose the location where you want to provision your transit gateway.

If you are using local routing, the specified location limits you to connect VPCs located in that region only. If you are using global routing, the specified location affects network latency, so choose the region closest to the resources that you need connected.
7. Add connections to your transit gateway now, or after it has been provisioned.



1. Select the network connection to be attached to the transit gateway. To add connections later, see [Adding a connection](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-adding-connections).

You can add a new connection on the same account as the connection type, or request to connect to a network in another account.

Select from the following connection types:



* Classic infrastructure networks allow you to connect to IBM Cloud classic resources. Only one classic infrastructure connection is allowed per account.
* VPC networks can contain compute resources, allowing you to connect to your account's VPC resources, or, with approval, another account's VPC resources.
* Unbound GRE tunnel allows a transit gateway to connect to overlay networks hosted on classic infrastructure resources. For more information, see [Creating an Unbound Generic Routing Encapsulation tunnel connection](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-unbound-gre-connection).
* Direct Link creates a network connection to and from Direct Link gateways so that there is a secure connection to on-premises networks and other resources connected to the transit gateway.

If you select Direct Link, you must also log in to the [Direct Link console](https://cloud.ibm.com/interconnectivity/direct-link) and specify Transit Gateway as the type of network connection for your direct link.
For the rest of the calls, you'll need to know the ID of the newly created report. Save the ID in a variable, for example:

route_report="22222222-c540-4766-a196-14368f328eb2"

To verify that the variable was saved, run echo $route_report and make sure the response is not empty.
4. Wait for the report to become active, then you can view its details:

curl -X GET "$transit_api_endpoint/v1/transit_gateways/$transit_gateway/route_reports/$route_report?version=$api_version" -H "Authorization: $iam_token"







 Addressing route conflicts 

Conflicting routes can cause errors, which you can see in the Conflict column of the Routes view.

Conflicting routes are not dropped from routing tables. Any conflicts that you see in the Conflict column are presented merely for information, so that you can easily spot potential problems in your routing, and decide how to address them, if at all. Overlapping routes may also be intentional, such as for HA purposes.

If there are multiple conflicts, click the link to open a side panel with more information. After you resolve the conflicts, generate a new report.

When diagnosing conflicting routes, keep in the mind the following traffic flow considerations:



* If the advertised prefixes match exactly, or have the same prefix length and AS Path length, the route preferred by the BGP protocol on the IBM Cloud router is non-deterministic and might change over time. Therefore, you might expect to see routes working as expected, and then suddenly not. In a redundant GRE or Direct Link situation, this can be fine, but if you have stateful firewalls, this can be an issue in that the return path to a customer site (or virtual router) can shift if the preferred route changes.
* If the prefix lengths of two routes are different (for example, 192.168.0.0/16 and 192.168.0.0/24), the more precise prefix is preferred. In this example, the connection advertising the /24 prefix would be used for all matching IPs.
"href": "$vpc_api_endpoint/v1/virtual_network_interface/710y-b8aa945c-7eac-4c15-bad6-a56db9d1e9bd",
"id": "710y-b8aa945c-7eac-4c15-bad6-a56db9d1e9bd",
"name": "enlace-traverse-oat-console",
"resource_type": "VirtualNetworkInterface"
},
"vpc": {
"crn": "crn:[...]",
"href": "$vpc_api_endpoint/v1/vpcs/82fa21ae-a645-4dd5-9136-d48a723bf00e",
"id": "82fa21ae-a645-4dd5-9136-d48a723bf00e",
"name": "my-vpc-2",
"resource_type": "vpc"
}
}
Show more





 Creating a file share and mount target by specifying a subnet and security group 

New

To create the mount target network interface, make a POST /shares request and specify a subnet and security group.

In this example, the mount_targets property specifies a subnet ID and security group ID. When the transit_encryption property is set to user_managed, it enables encryption in transit by using an instance identity certificate. The default value is none, which disables encryption in transit.

curl -X POST "$vpc_api_endpoint/v1/shares?version=2023-06-11&generation=2&maturity=beta" 
-H "Authorization: $iam_token" 
-d '{
"size": 20,
"name": "myshare-3",
"profile": {
"name": "dp2"
},
"zone": {
Extra requirements exist in Classic Infrastructure networking to enable the Transit Gateway, be sure to review documentation before you change your Classic Infrastructure or VPC Infrastructure networking topology and configuration.

It is advised that your networking department contact [IBM Cloud Support](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatargetting-support) after determining the layout of your landscape and the connectivity that is required on the SAP application layer.





 Networking protection 

IBM Cloud® offers further protection mechanisms that can provide your Virtual Servers for VPC with a layer of security that you can configure and adapt anytime. Two key principles are: * Network Access Control Lists (ACL): Available for use by all subnets in all zones. ACLs attach to a subnet and provide subnet-level protection by limiting a subnet's inbound and outbound traffic. * Security Groups: Available for use by all subnets on all zones that are attached to a vNIC of any server that provides instance-level protection by acting as a firewall to restrict a vNIC inbound and outbound traffic.

For more information, see [Security in your VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-security-in-your-vpc).



 Subnets to separate traffic 

If you want to separate different network traffic types in your landscape, either because of security restrictions or because of throughput considerations, you can configure and attach multiple subnets to your VPC and make them available to your compute resources, too.





 Network Access Control List 

Network Access Control Lists (ACLs) are used to manage allow and deny rules on a subnet level. ACLs are used to manage network traffic between subnets, too. The default ACL for a subnet opens the subnet for all traffic. If you wanted more strict security measures, you would need to add rules to the ACL. When you add rules, keep in mind that required services like DNS or OS patch and packages downloads might be affected by those rules.
[Only route enterprise to spoke through the firewall](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/vpc-transit/vpc-transit-part1-fw.svg)

Only route enterprise to spoke through the firewall



1. enterprise <-> transit
2. spoke <-> transit
3. spoke <-> spoke
4. enterprise <--transit firewall-router--> spoke



This routing can be achieved by adding these routes to the transit ingress route table:



 Zone Destination Next hop 

 Dallas 1 10.1.0.0/24 Delegate 
 Dallas 2 10.2.0.0/24 Delegate 
 Dallas 3 10.3.0.0/24 Delegate 





1. To observe the current value of the ingress route table visit the [Routing tables for VPC](https://cloud.ibm.com/vpc-ext/network/routingTables) in the IBM Cloud console. Select the transit VPC from the drop down and then select the tgw-ingress routing table.
2. Make the changes to the routing table by applying the transit_ingress layer:



./apply.sh transit_ingress_tf



1. Refresh the browser display of the routing table to observe the new routes.
2. Run the test suite.

Your expected results are: All tests will result in PASSED with the exception of enterprise <-> spoke(s) that are cross zones.

pytest -m "curl and lz1 and (rz1 or rz2)"







 Step 8: Add Spoke Egress routes to fix Asymmetric Routing 

This step will identify and fix a cross zone asymmetric routing issue. The diagram below shows the successful routes in green. Notice the arrow in both directions. One of the unsuccessful routes has an initial route in blue and an unsuccessful return route in red:

Zoom

!
To ensure successful connectivity with the classic infrastructure, do not use prefixes in your VPCs that overlap with the 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15, and 10.254.0.0/16 blocks. Also, don't use addresses from your classic infrastructure subnets. To view a list of your classic infrastructure subnets, see [View all subnets](https://cloud.ibm.com/docs/subnets?topic=subnets-view-all-subnets).
* Classic virtual server instances can have both a private (eth0) and a public (eth1) network interface. Currently, the routing tables for these interfaces point the default gateway to the public interface (eth1). You might have to add routing entries to route the subnets from other VPCs through the private interface.
* All of your IBM Cloud classic infrastructure networks across [MZRs](https://cloud.ibm.com/docs/overview?topic=overview-locationsmzr-table) are accessible through this connection, regardless of the location of the transit gateway or the routing type specified.
* Classic infrastructure resources located in these [data centers](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-tg-locationsszr-table) connect through a transit gateway to VPC resources.
* When classic infrastructure is connected to a transit gateway, it also includes any "Classic Access VPCs" attached to the account, because the subnets for these VPCs are associated with the classic infrastructure VRF. This is the only way to connect a transit gateway to a Classic Access VPC: by connecting the entire classic infrastructure to the transit gateway (instead of the specific Classic Access VPCs).







 Generic Routing Encapsulation (GRE) connection considerations 

When configuring a GRE tunnel, you must specify an availability zone in which to create the tunnel. Because of this, if for some reason that zone becomes unavailable, any network connected through a GRE tunnel on that zone is unreachable.
Zoom

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

Firewall

Connectivity from the enterprise to a spoke is achieved through a Network Function Virtualization, [NFV](https://cloud.ibm.com/docs/vpc?topic=vpc-about-vnf), firewall-router instance in the transit VPC. In production you can choose one from the catalog or bring your own. This demonstration will use an Ubuntu stock image with kernel iptables set up to forward all packets from the source to destination. In this tutorial, no firewall inspection is actually performed.

The Terraform configuration will configure the firewall-router instance with [allow_ip_spoofing](https://cloud.ibm.com/docs/vpc?topic=vpc-ip-spoofing-about). You must [enable IP spoofing checks](https://cloud.ibm.com/docs/vpc?topic=vpc-ip-spoofing-aboutip-spoofing-enable-check) before continuing.



1. Apply the firewall_tf layer:

./apply.sh firewall_tf
2. Run the test suite.

Your expected results are: Connectivity within a VPC, enterprise -> transit, enterprise <-> spoke same zone pass. But all transit -> spoke, all transit -> enterprise and enterprise <--> spoke cross zone fail due to asymmetric routing issues.

pytest -m "curl and lz1 and (rz1 or rz2)"
'complexType': 'SoftLayer_Container_Product_Order_Network_LoadBalancer_AsAService',
'name': name,
'description': desc,
'location': datacenter,
'packageId': package_id,
'useHourlyPricing': True, Required since LBaaS is an hourly service
'prices': [{'id': price_id} for price_id in prices],
'protocolConfigurations': protocols,
'subnets': [{'id': subnet_id}]
}

try:
 If verify=True it checks your order for errors.
 It orders the lbaas if False.
if verify:
response = self.client['Product_Order'].verifyOrder(orderData)
else:
response = self.client['Product_Order'].placeOrder(orderData)

return response
except SoftLayer.SoftLayerAPIError as e:
print("Unable to place the order: %s, %s" % (e.faultCode, e.faultString))

if __name__ == "__main__":
lbaas = LBaaSExample()

package_name = 'Load Balancer As A Service (LBaaS)'
location = 'MEXICO'
name = 'My-LBaaS-name'
description = 'A description sample'

 Set False for private network
is_public = True

protocols = [
{
"backendPort": 80,
"backendProtocol": "HTTP",
"frontendPort": 8080,
"frontendProtocol": "HTTP",
"loadBalancingMethod": "ROUNDROBIN", ROUNDROBIN, LEASTCONNECTION, WEIGHTED_RR
"maxConn": 1000
}
]

 remove verify=True to place the order
receipt = lbaas.order_lbaas(package_name, location, name, description,