vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Transit gateways and their connections can take several minutes after provisioning before they are available.
* Be descriptive when naming your transit gateway connections. When connecting to resources across accounts, you must specify a connection name. When connecting to resources in the same account as the transit gateway, the VPC name or the word 'classic' is the default selection and can be modified.
* IBM Cloud Transit Gateway is a multi-tenant application, where a single instance of the software, and its supporting infrastructure, serves multiple customers. As a result, monitoring your bandwidth use is important. If you use too much bandwidth, your transit gateway instance may be suspended. If you suspect this is the case, check the transit gateway instance connection status to see if it is in a Suspended state. If so, [contact support](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-getting-help-and-support) to reinstate it.







 Classic infrastructure connection considerations 



* To use a transit gateway to connect your VPCs to your IBM Cloud classic infrastructure, you must enable your classic account for virtual routing and forwarding (VRF) and link it to your IBM Cloud account. For information on enabling your account for VRF, see [Enabling VRF and service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpoint).
* When you connect a VPC and the classic infrastructure to a transit gateway, all prefixes in the VPC become visible to the classic infrastructure VRF, which uses IP addresses in the 10.0.0.0/8 space. 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).
Each status on the data transfer case indicates the phase of the transfer process for the hardware that was submitted to the data center. Refer to the table for specific details on each status:



Table 1. Status definitions.

 Status Definition 

 Sent To SoftLayer The Data Transfer Request was submitted by the user and the hardware is being shipped to the selected data center. 
 Received by SoftLayer The shipment was received by the data center, the device was assigned a serial number and was scanned into the IBM Cloud® system. 
 Connect The hardware is connected to the device. 
 Connected An iSCSI target is created for the device. 
 Request for Extension Client requested an extension on the two-week connection time. 
 Request for Return Client requested the return of hardware. 
 Disconnect Disconnection of hardware was initiated. 
 Disconnected Target is safely detached. 
 Destroyed The device was destroyed on site by following the IBM Cloud® HDD destruction procedure. 
 Return by SoftLayer Hardware was packaged and shipped to the return address provided in the original request. 







 Can I mount DTS on VMware® ESXi servers? 

IBM Cloud® does not support mounting a DTS device on a VMware® VCenter server. You can attach the DTS device to Linux® and Windows® operating systems.
Capacity management handles the overall available capacity on the transit gateway and is subject to our weekly capacity management review. When the device reaches roughly a 50% load, we augment the connectivity to the device.
* What scalability options do I have for my transit gateway? Does it manage itself? How do I know if it's reaching maximum capacity?

The IBM Cloud infrastructure manages all transit gateways. There are no scalability options available.
* How do you prevent Distributed Denial of Service (DDoS) attacks? What restrictions do you have in place?

Neither third-parties nor the internet can see your transit gateway traffic. As no critical information, such as IP router addresses, is open to anyone but you, DDoS attacks cannot bring down the network. In addition, a typical Multi-protocol Label Switching service (MPLS) uses packet filtering and applies access control lists (ACLs) to limit access. Only the ports with routing protocols from a specific area of the network can access the information.
* How does my transit gateway handle encryption for connectivity between VPCs?

IBM Cloud Transit Gateway does not perform encryption; it only provides connectivity. Encryption between VPCs is your own responsibility.

It is an RFC-2547-based platform where the core network and network address are 100% concealed.
* What are the tools for monitoring the consumption of resources associated with the service, as well as the costs and the quality of the service?

IBM Cloud Transit Gateway is integrated into the [IBM Cloud usage dashboard](https://cloud.ibm.com/docs/billing-usage?topic=billing-usage-viewingusage), which provides a summary of estimated charges for all services and resources that are used per month in your organizations. This includes the number of connections and the amount of traffic flowing across your transit gateways. IBM Cloud Transit Gateway usage is billed and reported as part of the [IBM Cloud invoice process](https://cloud.ibm.com/docs/billing-usage?topic=billing-usage-managing-invoices).
* Are there notifications through email for events of unavailability of the service?
=============== 12 failed, 4 passed, 276 deselected in 72.80s (0:01:12) ================
Show more



A change to the network configuration can take a couple of test runs for the underlying VPC network system to become consistent. If you do not see the expected results initially be prepared to run the test again a couple of times.

The r- and l- stand for right and left. The middle part of the name identifies enterprise, transit, spoke0, spoke1, ... The z1, z2, ... identify the zone. The test will SSH to the left instance. On the left instance the connectivity to the right instance is attempted. The test_curl performs a curl connectivity on the left instance to the right instance.

The test test_curl[l-enterprise-z1 -> r-transit-z1]:



1. SSH to a test instance in enterprise zone 1.
2. Execute a curl to transit zone 1.
3. Assert the return string contains the ID of transit zone 1 to mark pass or fail.



The README.md in the companion [GitHub Repository](https://github.com/IBM-Cloud/vpc-transit) has more details and the source code.





 Step 4: Connect Transit and Spokes via Transit Gateway 

Provision a IBM Cloud Transit Gateway to connect the transit <-> spoke(s) and spoke(s) <-> spoke(s).

Zoom

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

Spoke gateway



1. Apply the layer:

./apply.sh transit_spoke_tgw_tf
2.
A GRE tunnel connection allows a transit gateway to connect to overlay networks hosted on classic infrastructure resources.





 01 March 2021 

Classic infrastructure connections across IBM Cloud accounts
: You can now connect to IBM Cloud® classic infrastructure in another IBM Cloud account by providing the cloud account ID when adding a connection to your transit gateway. The account containing the classic infrastructure is then able to view the gateway and all of its connections, and must choose to opt-in to allow account-to-account interconnectivity.
: For more information, see [Adding a cross-account connection](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-adding-cross-account-connections).





 01 January 2021 

Connect networks to multiple local gateways
: You can now connect networks, VPCs, and classic connections to multiple local transit gateways. Previously, you could connect a network only to a single transit gateway. Now traffic between local networks can use a local gateway. In addition, if you need to connect to a remote network, you can attach to a global gateway. Routing of traffic between networks takes an optimized path (if multiple connections exist), meaning local traffic stays local to the region and is not charged.
: The limit for the number of gateways per account has been updated to ten, and the limit of gateways per region to five. You can open an [IBM Support case](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatarusing-avatar) if you need to expand your service limits further.





 01 July 2020 

VPC connections across IBM Cloud accounts
: You can now connect to a VPC in another IBM Cloud account by providing the CRN of the VPC when adding a connection to your transit gateway. The account containing the VPC is then able to view the gateway and all of its connections, and must choose to opt-in to allow account-to-account interconnectivity for that VPC.
: For more information, see [Adding a cross-account connection](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-adding-cross-account-connections&interface=ui).
Centralize communication through a VPC Transit Hub and Spoke architecture - Part one 

This tutorial may incur costs. Use the [Cost Estimator](https://cloud.ibm.com/estimator/review) to generate a cost estimate based on your projected usage.

A Virtual Private Cloud (VPC) provides network isolation and security in the IBM Cloud. A VPC can be a building block that encapsulates a corporate division (marketing, development, accounting, ...) or a collection of microservices owned by a DevSecOps team. VPCs can be connected to an on-premises enterprise and each other. This may create the need to route traffic through centralized firewall-gateway appliances. This tutorial will walk through the implementation of a hub and spoke architecture depicted in this high-level view:

Zoom

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

Figure 1. Architecture diagram of the tutorial

This is part one of a two part tutorial. This part will introduce the VPC transit hub as the conduit to the enterprise. Enterprise to spoke VPC connectivity between microservices will be discussed and implemented. This architecture will support a number of scenarios:



* The hub is a central point of traffic routing between enterprise and the cloud.
* Enterprise to cloud traffic is routed through the hub, and can be monitored, and logged through Network Function Virtualization (NFV) appliance running inside the hub.
* The hub can monitor all or some of the traffic - spoke <-> spoke, spoke <-> transit, or spoke <-> enterprise.
* The hub can be the repository for shared microservices used by spokes.
Centralize communication through a VPC Transit Hub and Spoke architecture - Part two 

This tutorial may incur costs. Use the [Cost Estimator](https://cloud.ibm.com/estimator/review) to generate a cost estimate based on your projected usage.

A Virtual Private Cloud (VPC) provides network isolation and security in the IBM Cloud. A VPC can be a building block that encapsulates a corporate division (marketing, development, accounting, ...) or a collection of microservices owned by a DevSecOps team. VPCs can be connected to an on-premises enterprise and each other. This may create the need to route traffic through centralized firewall-gateway appliances. This tutorial will walk through the implementation of a hub and spoke architecture depicted in this high-level view:

Zoom

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

Figure 1. Architecture diagram of the tutorial

This is part two of a two part tutorial. This part will focus on routing all traffic between VPCs through a transit hub firewall-router. A scalable firewall-router using a Network Load Balancer is discussed and implemented. Private DNS is used for both for microservice identification and IBM Cloud service instance identification using a virtual private endpoint gateway.

This tutorial is stand alone and it is not required to execute the steps in [part one](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-transit1). If you are not familiar with VPC, network IP layout and planning in the IBM Cloud, Transit Gateway, IBM Cloud® Direct Link or asymmetric routing consider reading through part one.

The hub and spoke model supports a number of different scenarios:
* [Interconnect two or more VPCs in the same MZR](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-aboutuse-case-1-interconnect-two-or-more-vpcs-in-the-same-mzr)
* [Planning for Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-helpful-tips)
* [Team based privacy that uses IAM, VPC, Transit Gateway, and DNS](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-tg-dns-iam)







 Related controls in IBM Cloud Framework for Financial Services 

The following [IBM Cloud Framework for Financial Services controls](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutframework-control-requirements) are most related to this guidance. However, in addition to following the guidance here, do your own due diligence to ensure you meet the requirements.



Table 1. Related controls in IBM Cloud Framework for Financial Services

 Family Control 

 Access Control (AC) [AC-20 Use of External Information Systems](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-ac-20) 
 Security Assessment and Authorization (CA) [CA-3 System Interconnections](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-ca-3)
Networking <br><br> * [VPC infrastructure services](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environment&interface=api)<br> * [Direct Link](https://cloud.ibm.com/apidocs/direct_link)<br> * [Transit Gateway](https://cloud.ibm.com/apidocs/transit-gateway)<br><br><br> 
 Storage <br><br> * [Block Storage for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environment)<br> * [Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-compatibility-api)<br><br><br> <br><br> * [Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-compatibility-api)<br><br><br> 
 Security <br><br> * [Hyper Protect Crypto Services](https://cloud.ibm.com/apidocs/hs-crypto)<br><br><br> <br><br> * [Hyper Protect Crypto Services](https://cloud.ibm.com/apidocs/hs-crypto)<br><br><br> <br><br> * [App ID](https://us-south.appid.cloud.ibm.com/swagger-ui//)<br><br><br>
For more information, see [Prepare Standalone Hosts as Transport Nodes or Prepare ESXi Cluster Hosts as Transport Nodes](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/installation/GUID-D7CA778B-6554-4A23-879D-4BC336E01031.htmlGUID-D7CA778B-6554-4A23-879D-4BC336E01031).



When you deploy an NSX-T edge, you can think of it as an empty container. The NSX-T edge does not do anything until you create logical routers, it provides the compute backing for Tier 0 and Tier 1 logical routers.

Refer to [VMware Solution Architectures for IBM Cloud VPC](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vpc-ryo-nsx-t) for naming and architectural considerations.





 Step 5: Create a segment and port group for NSX-T edge deployment 



1. Create a NSX-T VLAN backed segment for the vlan transport zone using with the VLAN ID, e.g. 400. For more information, see [Adding a Segment](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-D018DB03-0C07-4980-887D-AF3B3E93EF63.html)
2. Create a Distributed port group for the overlay transport zine using the VLAN trunk, e.g. 0-4094. For more information, see [Configure VLAN Tagging on a Distributed Port Group or Distributed Port](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-D5960C77-0D19-4669-A00C-B05D58A422F8.html)
Release notes for IBM Cloud Transit Gateway 

Find out about new and updated features in IBM Cloud® Transit Gateway.



 22 June 2023 

Madrid multi-zone region (MZR) support





 24 April 2023 

Multi-account support for IBM Cloud Direct Link
: Transit Gateway now includes cross-account support for Direct Link connections. For more information, see [Ordering a transit gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-ordering-transit-gateway) and [Adding a cross-account connection](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-adding-cross-account-connections).





 30 November 2022 

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 resource. Unbound GRE tunnels have the following advantages over legacy GRE tunnels:



* The ability to receive classic network subnets from a classic connection.
* The ability to communicate through other unbound GRE tunnels on the same transit gateway.
* Do not require a classic connection on the transit gateway. The classic network's subnets will not be advertised to all the connections on the transit gateway and vice versa.



: See [Creating an Unbound Generic Routing Encapsulation tunnel connection](https://test.cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-unbound-gre-connection) for more information.





 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).





 15 November 2021
* --protocol - The transport protocol to use for this VPN server. One of: udp, tcp.
* --name - New name of the VPN server.
* --output - Specify output format, only JSON is supported. One of: JSON.
* -q, --quiet - Suppress verbose output.





 Command examples 



* Update a stand-alone VPN server to an HA VPN server by adding a second subnet from a different zone:

ibmcloud is vpn-server-update r134-aa88726e-8b34-4f97-992d-027df9c4bb36 --subnet 0716-6ec3e875-abfa-40f4-a7c5-7473f4b2a2e1,0726-61b2f53f-1e95-42a7-94ab-55de8f8cbdd5

Separate the two subnet IDs or names with a comma.
* Change the subnet of a VPN server, or downgrade from two subnets (HA VPN server) to one subnet (stand-alone VPN server). The specified subnet (for example, 0716-6ec3e875-abfa-40f4-a7c5-7473f4b2a2e1) replaces any existing subnets.

ibmcloud is vpn-server-update r134-aa88726e-8b34-4f97-992d-027df9c4bb36 --subnet 0716-6ec3e875-abfa-40f4-a7c5-7473f4b2a2e1









 Upgrading to an HA VPN server with the API 

To upgrade to an HA VPN server by using the API, follow these steps:



1. Set up your [API environment](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environmentapi-prerequisites-setup) with the correct variables.
2.
Layer 7 load balancing 

Both public and private application load balancers support layer 7 load balancing. Data traffic is distributed based on configured policies and rules. A policy defines the action to take, which means how the traffic is distributed, when the incoming request matches the rules that are associated with the policy.



 Policies 

You can define policies for HTTP and HTTPS listeners. For each policy, you must define one or more rules. The policy is applied only when all its rules are matched.

You can attach more than one policy to a listener. In general, a policy with the lowest priority is evaluated first. Each policy must have a different priority.

If the incoming request does not match the rules for any policy, the system request redirects to the configured HTTPS redirect listener, if present. Otherwise, the system redirects the request to the default pool of the listener. The HTTPS redirect has a higher precedence over the default pool on an HTTP listener.

The following actions are supported for a layer 7 policy:



* Reject - The request is denied with a 403 response.
* Redirect - The request is redirected to a configured URL and response code.
* Forward - The request is sent to a specific back-end pool.
* HTTPS Redirect - The HTTP request redirects to an HTTPS listener.







 Policy properties 



Table 1. Description of policy properties

 Property Description 

 Name The name of the policy. The name must be unique within the listener. 
 Action The action to take when all policy rules match. The acceptable values are reject, redirect, forward, and https_redirect. 
 Priority Policies are evaluated based on ascending order of priority. 
 URL The URL to which the request is redirected, if the action is set to redirect. 
 HTTP status code Status code of the response returned by the application load balancer when the action is set to redirect or https_redirect. The acceptable values are: 301, 302, 303, 307, or 308. 
 Target The back-end pool of virtual server instances to which the request is forwarded, if the action is set to forward.
* [External network requirements and security](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-security)



* [Do I need to allow any unique inbound traffic from internet-facing ports through firewalls to my location?](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-unique-inbound)
* [If IBM owns the Link tunnel, how can I validate that our data is inaccessible? My organization's security policy does not allow tunnels from our networks.](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-tunnel-data-inaccessible)
* [How do I make my data secure in transit?](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-data-secure-transit)



* [Encryption protocols](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-protocols)



* [TCP and TLS](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-tcp-tls)
* [HTTP and HTTPS](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-http-https)
* [HTTP tunnel](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-http-tunnel)
* [Server-side certificate authentication for TLS and HTTPS](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-server-side-cert)



* [Access and audit controls](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-audit-about)



* [Restricting access with source lists](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-source-lists)