vania-janet/multiturn-rag-retrieval-data huggingface dataset:
With IBM Cloud Transit Gateway, you can create a single transit gateway or multiple transit gateways to connect IBM Cloud VPCs. You can also connect your IBM Cloud classic infrastructure to a transit gateway to provide seamless communication with classic infrastructure resources. Any new resource that you connect to a transit gateway is automatically made available to every other resource connected to it. All data remains within the private IBM Cloud backbone and is optimized for performance.

Zoom

![Sample Transit Gateway use case](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/TGW_Multi-Multi.png)

Sample Transit Gateway use case

VPC A Networks

VPC B Networks

VPC Z Networks



Table 1. VPC A Networks

 IP Origin 

 10.100.0.0/24 from VPC A subnet 
 13.100.0.0/24 from VPC A subnet 
 10.101.0.0/24 from VPC B through Transit Gateway (local) 
 13.101.0.0/24 from VPC B through Transit Gateway (local) 
 10.111.0.0/24 from VPC Z through Transit Gateway (global) 
 13.111.0.0/24 from VPC Z through Transit Gateway (global) 







 Benefits of using these IBM Cloud options 

Benefits of these interconnectivity offerings include:



* Traffic between your on-premises network and your VPC network doesn't traverse the public internet. Traffic traverses a dedicated connection, or through a service provider with a dedicated connection.
* By bypassing the public internet, your traffic takes fewer hops, so there are fewer points of failure where your traffic might get dropped or disrupted.
* Move data to and from your on-premises data centers into the IBM Cloud with uninterrupted, consistent network performance while protecting sensitive, business-critical data.
* Save on data transfer rates to and from servers in every IBM Cloud data center across our private network, avoiding bandwidth fees.







 Routing considerations for IANA-registered IP assignments
[Asymmetric traffic needs to be fixed](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/includes/solution-tutorials/includes/solution-tutorials/images/vpc-transit/vpc-transit-asymmetric.svg)

Asymmetric traffic needs to be fixed



 Asymmetric Routing Limitation 

The remaining failures are cross zone failures enterprise <-> spoke(s).

Example failure:

FAILED py/test_transit.py::test_curl[l-enterprise-z1 -> r-spoke0-z2] - assert False

The blue line represents a TCP connection request from enterprise through the Transit Gateway: 192.168.0.4 <--TCP--> 10.2.1.4. The Transit Gateway will choose a transit VPC zone based on the matching address prefix. The matching address prefix for 10.2.1.4 is 10.2.1.0/24 in the lower zone.

The red line represents the TCP connection response to 192.168.0.4. The Transit Gateway delivers to the transit VPC using the matching address prefix 192.168.0.0/24 in the upper zone. The IBM Cloud VPC uses the industry standard state based routing for secure TCP connection tracking. This requires that the TCP connection pass through the same firewall-router in both directions. The VPC does not support tcp "Asymmetric Routing".

It is interesting to note that an attempt to ping using the ICMP protocol would not suffer from this limitation. ICMP does not require a stateful connection. Connectivity from 192.168.0.4 <--ICMP--> 10.2.1.4 via ICMP is possible. You can run the ping marked tests to verify via copy paste of the failed output. The l- is for left and r- is for right:

Expect success:

pytest -m ping -k 'l-enterprise-z1 and r-spoke0-z2'

Expect failure:
Designing an addressing plan for a VPC 

The first step in designing your IBM Cloud® Virtual Private Cloud is designing your addressing plan.

A properly designed addressing plan has two goals:



* It meets the communication requirements of VPC instances.
* It maintains flexibility for future growth.



This document gives an example of designing the addressing plan for a three-tiered web application, in which each tier is supported by multiple zones.

Although each IBM Cloud VPC deploys to a specific region, the VPC can span all of the zones within that region. IBM Cloud VPC defines a default address prefix for every zone. The address prefixes enable communication between VPC instances in different zones.

The same design steps are involved, no matter whether the application is contained completely on the cloud, or whether parts of the application are running in another location.

When you create VPC instances that you intend to interconnect by using [IBM Cloud Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-getting-started), avoid selecting Default address prefixes. Create your VPC instances with nonoverlapping prefixes for [successful connectivity](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-troubleshootingoverlapping-vpc-prefixes-and-classic-subnets).

When you create VPC instances that you also intend to interconnect with your IBM Cloud classic infrastructure by using [IBM Cloud Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-getting-started), do not use IP addresses in your instances in the 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15, and 10.254.0.0/16 blocks. Also, avoid IP addresses from your classic infrastructure subnets.

For more information about designing your VPC instances for use with IBM Cloud Transit Gateway, see [Planning for IBM Cloud Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-helpful-tips).



 Design considerations and assumptions
Transit Gateway CLI change log 

In this change log, you can learn about the latest changes, improvements, and updates for IBM Cloud® Transit Gateway.



 24 April 2023 

Direct Link multi-account support
: Changed command: You can now create a connection of type directlink to pass into the [connection-create](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-transit-gateway-cli&interface=uiconnection-create) command and create a direct link from a different account owner. Previously only connections of type vpc and classic were allowed.





 30 November 2022 

Unbound GRE tunnels
: You can now use an unbound Generic Routing Encapsulation (GRE) tunnel connection to connect endpoints, which allows a transit gateway to connect to overlay networks hosted on classic infrastructure resource.
: New commands:



* base-network-type - Network type of the base connection (classic). For use only with the unbound_gre_tunnel network type.
* network-account-id - ID of account to connect to a classic connection. For use only with the classic type when the account of the connection is different than the gateway's account.
* network-type - Network type of the GRE connection. Values are gre_tunnel or unbound_gre_tunnel. The default value is gre_tunnel.







 26 March 2022 

Network prefix filters
: Simplify the management of the IP addresses that you reference in your resources to route network traffic. You can create prefix filters to permit or deny specific routes on specific connections. These prefix filters are added to an ordered list that is processed sequentially. A default filter (permit or deny all prefixes) is then applied after the prefix filter list is processed. For more information, see [Adding and deleting prefix filters](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-adding-prefix-filters&interface=cli).





 15 November 2021 

Transit gateway route reports
: You can now request a route report, which shows all routes known to a transit gateway and each of its connections. The report shows:
* [IBM Cloud Transit Gateway overview](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-getting-started)
* [IBM Cloud VPC VPN overview](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-overview)
* [VPC IaaS endpoints](https://cloud.ibm.com/docs/vpc?topic=vpc-service-endpoints-for-vpcinfrastructure-as-a-service-iaas-endpoints)
* [VMware on Bare Metal VPC tutorial](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-bm-vmware)
Transportation use cases for IBM Cloud 

These use cases highlight how workloads on IBM Cloud® Kubernetes Service can take advantage of toolchains for rapid app updates and multi-region deployments across the globe. At the same time, these workloads can connect to existing back-end systems, use Watson AI for personalization, and access IOT data with IBM® Event Streams for IBM Cloud®.



 Shipping company increases availability of worldwide systems for business partner ecosystem 

An IT Exec has worldwide shipping routing and scheduling systems that partners interact with. Partners require up-to-the-minute information from these systems that access IoT device data. But, these systems were unable to scale across the globe with sufficient HA.

IBM Cloud Kubernetes Service scales containerized apps with five 9s of availability to meet growing demands. App deployments occur 40 times daily when Developers experiment easily, pushing changes to Development and Test systems quickly. The IoT Platform makes access to IoT data easy.

Key technologies:



* [Multi-regions for business partner ecosystem](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zonesregions-and-zones)
* [Horizontal scaling](https://cloud.ibm.com/docs/containers?topic=containers-plan_deployhighly_available_apps)
* [Open toolchains in IBM Cloud® Continuous Delivery](https://www.ibm.com/cloud/architecture/toolchains/)
* [Cloud services for innovation](https://www.ibm.com/cloud/productsanalytics)
* [IBM® Event Streams for IBM Cloud® to feed event data to apps](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-aboutabout)





 Context 

Shipping company increases availability of worldwide systems for business partner ecosystem



* Regional differences for shipping logistics made it difficult to keep up with growing number of partners in multiple countries. An example is the unique regulations and transit logistics, where the company must maintain consistent records across borders.
* Just-in-time data meant that the worldwide systems must be highly available to reduce lags in transit operations.
* You must implement and document application capabilities and configuration requirements in accordance with the cryptographic specifications provided in the Supplemental Guidance for Cryptography section of the CIO template.
* You must implement and document application capabilities and configuration requirements related to using cryptographic keys provided via [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-overview) to protect data in transit and at rest.



Most Relevant Control Groups or Controls:



Table 4. Related controls for data encryption

 Family Control
November 2022 | Transit gateway unbound GRE tunnels

You can now use an unbound Generic Routing Encapsulation (GRE) tunnel transit gateway connection to connect endpoints, which allows a transit gateway to connect to overlay networks hosted on classic infrastructure resources.

March 2022 | Transit gateway prefix filtering

Network prefix filters simplify the management of the IP addresses that you reference in your resources to route network traffic. You can create prefix filters to permit or deny specific routes on specific connections. These prefix filters are added to an ordered list that is processed sequentially. A default filter (permit or deny all prefixes) is applied after the prefix filter list is processed.
}

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









 Creating a transit gateway using Terraform 

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



Table 4. Argument references for creating a transit gateway

 Argument Details 

 location <br>Optional <br>Forces new resource <br>integer The location of the transit gateway. <br>Example: us-south 
 name <br>Required <br>string The unique user-defined name for the gateway. <br>Example: myGateway 
 global <br>Required <br>boolean The gateways with global routing (true) are able to connect to networks outside their associated region. 
 resource_group <br>Optional <br>Forces new resource <br>string The resource group ID where the transit gateway is to be created. 





 Example 

This example illustrates creating a transit gateway in Terraform:

resource "ibm_tg_gateway" "new_tg_gw"{
name="transit-gateway-1"
location="us-south"
global=true
resource_group="30951d2dff914dafb26455a88c0c0092"
}
Updating to "false" deselects this routing table. One of: false, true.
* --transit-gateway-ingress, --transit-gateway: If set to "true", this routing table is used to route traffic that originates from Transit Gateway to this VPC. For the routing to succeed, the VPC must not already have a routing table with this property set to "true". One of: false, true.
* --vpc-zone-ingress, --vpc-zone: If set to "true", this routing table is used to route traffic that originates from subnets in other zones in this VPC. For the routing to succeed, the VPC must not already have a routing table with this property set to "true". One of: false, true.
* --accept-routes-from-resource-type-filters, --ar-rtf: The comma-separated resource type filters that can create routes in this routing table. One of: vpn_server, vpn_gateway.
* --output: Specify output format, only JSON is supported. One of: JSON.
* -q, --quiet: Suppress verbose output.



--------------------







 ibmcloud is vpc-routing-table-update 

Update a VPC routing table.

ibmcloud is vpc-routing-table-update VPC ROUTING_TABLE [--name NEW_NAME] [--direct-link-ingress false | true] [--internet-ingress, --internet false | true] [--transit-gateway-ingress false | true] [--vpc-zone-ingress false | true] [--accept-routes-from-resource-type-filters, --ar-rtf vpn_server | vpn_gateway | --clean-all-accept-routes-from-filters, --cl-arf] [--output JSON] [-q, --quiet]



 Command examples
For example, if a particular network connection has reached its bandwidth capacity, data packets might temporarily queue up to wait for their turn to travel across that pathway. As another example, if a particular service provider’s network selects a network route that is not optimal, data packets can be sent hundreds or thousands of miles away from their destination in the process of getting to their destination! These kinds of delays and detours are the causes of higher network latency—and slower data transfers.

We express network latency in milliseconds (that’s 1,000 milliseconds per second). A few thousandths of a second may not mean much to us as we’re living our daily lives, but milliseconds often become a deciding factor in our web browsing or in our business transactions. For example, in the financial sector, milliseconds can mean billions of dollars of difference in gains or losses from trade transactions on a day-to-day basis.





 Common approaches that minimize network latency 

Given that our shared goal is to minimize latency, it makes sense to limit the number of potential variables that can affect the speed of the data’s movement. No provider can achieve complete control over how data travels across the internet, but here are some best practices to minimize network latency:



* Distribute data around the world: Customers in different locations can pull data from a location that’s geographically close to them. Because the data is closer to the customers, it is handed off fewer times. When data has a shorter distance to travel, routing is less likely to cause a significant performance impact.
* Provision servers with high-capacity network ports: Huge volumes of data can travel across a server every second. If packets are delayed due to fully saturated ports, milliseconds of time pass, pages load more slowly, download speeds drop, and users become unhappy.
* Understand how your providers route traffic: When you know more details about how your data is transferred to customers around the world, you can make better decisions about where you host your data.







 How IBM Cloud minimizes network latency 

To minimize latency, IBM Cloud took a unique approach to building our network. All of our data centers are connected to network points of presence (PoPs), and all of our network points of presence are connected to each other through our global backbone network.
VLAN spanning 

VLAN spanning enables all devices on an account to communicate with each other by using the private network.



 Understanding VLAN spanning 

In IBM Cloud®, VLAN spanning can be used for many different purposes and has an impact on device communication. To learn more about the basics of VLAN spanning before you get started, review the following information.



 How VLAN spanning works 

By enabling VLAN spanning, all of your routed traffic can travel between all private subnets, across all private VLANs on your account. VLAN spanning serves business needs that require the global communication of your routed traffic. For example, enable VLAN spanning if devices that reside on more than one private subnet need to communicate, whether on the same or different VLANs.

When spanning is enabled, it affects the entire account. You cannot exempt any subnets, VLANs, or devices from VLAN spanning. If you currently rely solely on private subnets to separate servers into roles or tiers, enabling VLAN spanning removes that separation.





 Default values 

By default, VLAN spanning is disabled. Devices on two different private subnets, whether on the same or different VLANs, can't send IP traffic to one another.





 Services that commonly require VLAN spanning 

Specific tutorials are available to help you set up VLAN spanning for your situation. See [Resources for VLAN spanning](https://cloud.ibm.com/docs/vlans?topic=vlans-other-resources-vlan-spanning) to access those tutorials.







 Managing VLAN spanning 

You can enable or disable VLAN spanning for your account. To update your account setting, follow these steps:



1. From your browser, open the [IBM Cloud console](https://cloud.ibm.com/) and log in to your account.
2. From the console, click the Menu icon ![menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) and select Classic Infrastructure.
3. Select Network > IP Management > VLANs.
4.
curl -X POST "https://transit.cloud.ibm.com/v1/transit_gateways/9f559c43-63f4-4da5-b306-b525a8ddb275/connections/6c1bdc19-4adb-4550-8cdc-ef3b74b739f8/prefix_filters?version=2020-03-31" -H "Authorization: Bearer $iam_token" -H "Content-Type: application/json" -d '{"action": "deny", "prefix": "10-10.0.10/30"}'





 Response 

The following response details show once you initiate the request:



Table 4. Response details for adding prefix filters

 Response body Details 

 action <br>Always included <br>string Whether to permit or deny the prefix filter <br>Possible values: [permit,deny] <br>Example: permit 
 created_at <br>Always included <br>date-time The date and time that this prefix filter was created 
 id <br>Always included <br>string Prefix filter identified <br>Example: 1a15dcab-7e30-45e1-b7c5-bc690eaa9865 
 prefix <br>Always included <br>string IP prefix and subnet mask <br>Example: 192.168.100.0/24 
 before <br>string Identifier of prefix filter to handle the ordering and follow semantics:<br><br><br><br> * When a filter references another filter in it's before field, then the filter making the reference is applied before the referenced filter. For example: if filter A references filter B in its before field, A is applied before B.<br> * When a new filter is added that has the same before as an existing filter, then the older filter has its before field updated to point to the new filter.
: The complex type of the order. The type begins with SoftLayer_Container_Product_Order_.

--extras
: JSON string that denotes extra data needs to be sent with the order.





 Examples 

This command places a quote for a VSI with 4 CPU, 16 GB RAM, 100 GB SAN disk, Ubuntu 16.04, and 1 Gbps public & private uplink in datacenter dal13.

ibmcloud sl order place-quote CLOUD_SERVER DALLAS13 GUEST_CORES_4,RAM_16_GB,REBOOT_REMOTE_CONSOLE,1_GBPS_PUBLIC_PRIVATE_NETWORK_UPLINKS,BANDWIDTH_0_GB_2,1_IP_ADDRESS,GUEST_DISK_100_GB_SAN,OS_UBUNTU_16_04_LTS_XENIAL_XERUS_MINIMAL_64_BIT_FOR_VSI,MONITORING_HOST_PING,NOTIFICATION_EMAIL_AND_TICKET,AUTOMATED_NOTIFICATION,UNLIMITED_SSL_VPN_USERS_1_PPTP_VPN_USER_PER_ACCOUNT,NESSUS_VULNERABILITY_ASSESSMENT_REPORTING --extras '{"virtualGuests": [{"hostname": "test", "domain": "softlayer.com"}]}' --complex-type SoftLayer_Container_Product_Order_Virtual_Guest --name "foobar" --send-email







 ibmcloud sl order preset-list 

List package presets:

ibmcloud sl order preset-list [OPTIONS] PACKAGE_KEYNAME



 Command options 

--keyword
: A word (or string) used to filter presets.





 Examples 

This command lists the presets for Bare Metal servers.

ibmcloud sl order preset-list BARE_METAL_SERVER
Connectivity issue basics 

There are several simple issues that might be causing your connectivity issues. Verify the following tasks to eliminate them as problems.



  Checking your permissions 

If you are encountering resource issues on the provisioning page, make sure you have the correct [IAM permissions](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-iam) in order to use IBM Cloud Transit Gateway and IBM Cloud VPC for the connections you are attempting to make.

If you cannot successfully provision a transit gateway, your account administrator may have disabled certain users' visibility to the [IBM Cloud Catalog](https://cloud.ibm.com/docs/account?topic=account-accountsaccounts).





  Using supported locations 

If you are not able to establish connectivity between networks interconnected by a transit gateway, ensure that your networks are located in one of the [Transit gateway supported locations](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-tg-locations). You will not be able to establish connectivity to a resource in an unsupported location.





  Working with security groups 

[Security Groups](https://cloud.ibm.com/docs/vpc?topic=vpc-using-security-groupsusing-security-groups) exist at the VSI level. Ensure that you allow the protocol you are using to egress from the originator and ingress at the target.





  Working with Access Control Lists 

Network Access Control Lists [ACLs](https://cloud.ibm.com/docs/vpc?topic=vpc-using-aclsusing-acls) are applied at the VPC level. By default, they allow all inbound and outbound traffic. Check if you have changed this default.





  Interconnecting VPCs 

You can create a single transit gateway or multiple transit gateways to interconnect more than one IBM Cloud VPCs. You can also connect your IBM Cloud classic infrastructure to a transit gateway to provide seamless communication with classic infrastructure resources. For more information, refer to [Interconnecting VPCs](https://cloud.ibm.com/docs/vpc?topic=vpc-interconnectivity&interface=cliinterconnecting-vpcs).