vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Sample Direct Link on-premises interconnect use case](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/includes/vpc/includes/vpc/images/direct-link-dedicated.png)

Example Direct Link on-premises interconnect use case
* IBM Cloud Direct Link Connect provides connectivity between your on-premises and IBM Cloud VPC networks through a supported service provider. A service provider connection is useful if your data center is in a physical location that can't reach a dedicated colocation facility, or if your data needs don't warrant a 5 Gbps+ connection. Connect service providers are often used to facilitate multicloud connectivity (public clouds from multiple vendors) through their network. Connect service providers offer layer 2 connectivity, layer 3 connectivity, or both. Work with your service provider to understand their offerings and requirements.



* VPN for VPC can securely connect your virtual private cloud to another private network. You can use VPN to set up an IPsec site-to-site tunnel between your VPC and your on-premises private network or another VPC. See [Connecting to your on-premises network using a VPN gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-onprem-example) for details.







 Interconnecting VPCs 

IBM Cloud Transit Gateway provisions and defines connections between resources on the IBM Cloud network, providing private interconnectivity between IBM Cloud data centers worldwide. IBM Cloud Transit Gateway provides a central hub for connectivity, making it easier to provision and manage your networks. 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

!
[VPC-to-classic and BCR peering with Transit Gateway use case](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/includes/vpc/includes/vpc/images/vpc-classic-transit-gateway.png)

VPC-to-classic and BCR peering with Transit Gateway use case

VPC A Networks



Table 14. VPC B Networks

 IP Origin 

 10.100.0.0/24 from VPC A subnet 
 13.100.0.0/24 from VPC A subnet 
 13.111.0.0/24 from Classic through Transit Gateway 



VPC A Default (Egress) Routing Table



Table 15. VPC A Default (Egress) Routing Table

 Destination Action Next Hop Location 

 13.0.0.0/8 Delegate-VPC <br><br> * <br><br><br> Dallas 1 
 13.0.0.0/8 Delegate-VPC <br><br> * <br><br><br> Dallas 2 
 13.0.0.0/8 Delegate-VPC <br><br> * <br><br><br> Dallas 3 









 Related links 

To learn about these offerings:



* [Get started with IBM Cloud Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl)
* [Get started with IBM Cloud Transit Gateway](https://cloud.ibm.com/docs/transit-gateway)
* [Get started with VPN for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-using-vpn)
* Classic routes are advertised through an unbound GRE tunnel.
* Unbound GRE tunnels can communicate through other unbound GRE tunnels connected to the same transit gateway in the same availability zone.
* Unbound GRE tunnels cannot communicate with other unbound GRE tunnels on the same transit gateway if they are in a different availability zone. Unbound GRE tunnels in this scenario cannot be relied on for network isolation.



If you require network isolation, consider using separate transit gateways.



* Unbound GRE tunnels do not require a classic connection on the transit gateway. Classic network subnets will not be advertised to the connections on the transit gateway (or vice versa).
* The default number of unique base networks that can be targeted by unbound GRE tunnel connections is limited to 5. You can open an [IBM Support case](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatarusing-avatar) if you need these service limits expanded.



For more information and a use case example, refer to [Connect networks using a High Availability GRE tunnel](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-aboutuse-case-8).





 Direct Link connection consideration 

You can create Direct Link connections to a transit gateway to allow on-premises networks to connect to other networks in IBM Cloud. After the direct link connects to the transit gateway, the on-premises network receives access to all other transit gateway connections. Likewise, all other networks connected to the transit gateway have access to the on-premises network. Direct Link connections follow the same process for physical or virtual cross connections as the standard Direct Link offering. After the connection is deleted from a transit gateway, the transit gateway operates as if it was never connected to a direct link.

The same network subnet considerations for transit gateway connections also apply to Direct Link connections. To ensure successful connectivity, do not use prefixes in your Direct Link connected network that overlap with other connections.





 VPC connection consideration 

IBM Cloud VPC permits the use of RFC-1918 and IANA-registered IPv4 address space, privately within your VPC, with some exceptions in the IANA special-purpose ranges, and select ranges assigned to IBM Cloud services.
[Implement context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create&interface=ui) rules to further control access to all resources.

In this tutorial you created a hub VPC and a set of spoke VPCs. You identified the required Availability Zones for the architecture and created a set of subnets in the VPCs. You created a transit VPC firewall-router in each zone for centralized monitoring. Test instances were used to verify connectivity and identify potential problems. Routing table routes were used to identify the traffic paths required.





 Remove resources 

It is not required to remove the resources if you plan to continue with the the second part of this tutorial.

Execute terraform destroy in all directories in reverse order using the ./apply.sh command:

./apply.sh -d : spokes_egress_tf





 Expand the tutorial 

You are encouraged to continue on to [part two](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-transit2) of this tutorial where all cross VPC traffic is routed through the firewall-router, VPE for VPC and DNS are examined.

Your architecture will likely be different than the one presented but will likely be constructed from the fundamental components discussed here. Ideas to expand this tutorial:



* Integrate incoming public Internet access using [IBM Cloud® Internet Services](https://cloud.ibm.com/docs/cis?topic=cis-getting-started).
* Add [flow log capture](https://cloud.ibm.com/docs/vpc?topic=vpc-flow-logs) in the transit.
* Put each of the spokes in a separate account in an [enterprise](https://cloud.ibm.com/docs/account?topic=account-enterprise-tutorialaccount_groups_tutorial).
* Force some of the spoke to spoke traffic through the firewall and some not through the firewall.
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/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 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.
Networking <br><br> * [VPC infrastructure services](https://cloud.ibm.com/docs/vpc?topic=ibm-cloud-provider-for-terraform-getting-started)<br> * [Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-terraform-setup-dl)<br> * [Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-terraform-setup-tgw)<br><br><br> 
 Storage <br><br> * [Block Storage for VPC](https://cloud.ibm.com/docs/vpc?topic=ibm-cloud-provider-for-terraform-getting-started)<br> * [Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-about-terraform)<br><br><br> <br><br> * [Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-about-terraform)<br><br><br> 
 Security <br><br> * [Hyper Protect Crypto Services](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/hpcs)<br><br><br> <br><br> * [Hyper Protect Crypto Services](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/hpcs)<br><br><br> <br><br> * [App ID](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/appid_action_url)<br><br><br>
* The organization shall maintain a catalog of all customer metadata processed and/or transmitted by the organization on behalf of the customer. Metadata should be defined by each customer.
* The organization must document all information flows that involve the transfer of customer data. An information flow control policy must be developed and maintained that indicates the source and destination of each flow, the system of record and whether the information is altered during transmission.







 NIST supplemental guidance 

Security plans relate security requirements to a set of security controls and control enhancements. Security plans also describe, at a high level, how the security controls and control enhancements meet those security requirements, but do not provide detailed, technical descriptions of the specific design or implementation of the controls/enhancements. Security plans contain sufficient information (including the specification of parameter values for assignment and selection statements either explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented as intended. Organizations can also apply tailoring guidance to the security control baselines in Appendix D and CNSS Instruction 1253 to develop overlays for community-wide use or to address specialized requirements, technologies, or missions/environments of operation (e.g., DoD-tactical, Federal Public Key Infrastructure, or Federal Identity, Credential, and Access Management, space operations). Appendix I provides guidance on developing overlays. Security plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition. For example, security plans do not contain detailed contingency plan or incident response plan information but instead provide explicitly or by reference, sufficient information to define what needs to be accomplished by those plans.
Context-based restrictions protect only the actions associated with the [Transit Gateway API](https://cloud.ibm.com/apidocs/transit-gateway). Actions associated with the following platform APIs are not protected by context-based restrictions. Reference the API docs for the specific action IDs.



* [Resource Instance APIs](https://cloud.ibm.com/apidocs/resource-controller/resource-controllerlist-resource-instances)
* [Resource Keys APIs](https://cloud.ibm.com/apidocs/resource-controller/resource-controllerlist-resource-keys)
* [Resource Bindings APIs](https://cloud.ibm.com/apidocs/resource-controller/resource-controllerlist-resource-bindings)
* [Resource Aliases APIs](https://cloud.ibm.com/apidocs/resource-controller/resource-controllerlist-resource-aliases)
* [IAM Policy APIs](https://cloud.ibm.com/apidocs/iam-policy-managementlist-policies)
* [Global Search APIs](https://cloud.ibm.com/apidocs/search)
* Global Tagging [Attach](https://cloud.ibm.com/apidocs/taggingattach-tag) and [Detach](https://cloud.ibm.com/apidocs/taggingdetach-tag) APIs
* [Context-based Restriction Rule APIs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-rule)







 Creating rules 

Context-based restrictions for the transit service can be scoped to a Transit Service resource type. Since the Transit Service has only one applicable resource type, it is set to gateway.

Additionally, rules can be scoped to a specific instance of the service or a resource group by using resource attributes.



 Creating rules from the CLI 



1.
Networking <br><br> * [VPC infrastructure services](https://cloud.ibm.com/docs/vpc?topic=vpc-manage-security-compliance)<br> * [Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-manage-security-compliance)<br> * [Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-manage-security-compliance)<br><br><br> 
 Storage <br><br> * [Block Storage for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-manage-security-compliance)<br> * [Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-manage-security-compliance)<br><br><br> <br><br> * [Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-manage-security-compliance)<br><br><br> 
 Security <br><br> * [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-security-compliance)<br><br><br> <br><br> * [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-security-compliance)<br><br><br> <br><br> * [App ID](https://cloud.ibm.com/docs/appid?topic=appid-manage-security-compliance)<br><br><br>
* --routing: Optional: Gateway routing of resources (global | local). Select global to connect resources across regions. Changing routing from global to local requires all existing connections to be local.
* --output json: Optional: Specify if you want the output displayed in JSON format.
* --help | -h: Optional: Get help on this command.





 Example 

This example illustrates updating a gateway with a routing value of global:

ibmcloud tg gwu $gateway --routing global







 Changing your configuration with the API 

You can update your transit gateway's name, global parameters, or both with the API.



 Request 

To change the configuration on your transit gateway, set the following parameters:



Table 1. Path parameters for changing your configuration

 Path Parameters Details 

 id <br>Required <br>string The transit gateway identifier 





Table 2. Query parameters for changing your configuration

 Query parameters Details 

 version <br>Required <br>string Requests the version of the API as of a date in the format YYYY-MM-DD. Any date up to the current date may be provided. Specify the current date to request the latest version. <br>Possible values: Value must match regular expression ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ 
 Request Body <br>Required <br>TGPatchTemplate Update a transit gateway 
 global <br>global Allow global routing for a transit gateway <br>Example: true 
 name <br>Name The user-defined name for this transit gateway connection. <br>Possible values: 1 ≤ length ≤ 63, Value must match regular expression ^([a-zA-Z] 





 Example Request 

This example illustrates changing your configuration with the API:

PATCH /transit_gateways/{id}
"{base_url}/transit_gateways/{id}?version={version}"
{
"global": true,
"name": "my-transit-gateway"
}







 Response 

The following response shows once you initiate the request:



Table 3. Initiation request response
Inbound data transfer to IBM Cloud is free. Data transfer for [egress](https://cloud.ibm.com/docs/dl?topic=dl-pricing-for-ibm-cloud-dlmetered-data-transfer-charge) varies based on region. Global routing (access to all IBM Cloud data centers globally) is free. 







 Connection Patterns 

The following pattern depicts how individual infrastructure (VPC and Classic) can be added as connections ![dl-directconnections](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/directlink/DL_Pattern_VPC_DirectConnections.png) In above pattern, each connections has its own VRF and connection#1 prefixes cannot communicate with connection#2 prefixes by default.

The following pattern depicts how Transit Gateway (VPC and Classic) can be added as connection and advertise all the learnt routes from VPC and Classic infrastructure across accounts ![dl-directconnections](https://cloud.ibm.com/docs-content/v1/content/d50364af907081c3c38f99c11f35dd9cab4b2510/vpc-journey/images/directlink/DL_Pattern_VPC_TransitGW.png) In above pattern, transit GW will provide connections across infrastructures within IBMCloud and as well advertise all its prefixes to Directlink GW





 Ordering Direct Link 



* Detailed steps (including screenshots) to order Direct Link Dedicated are available in the [documentation](https://cloud.ibm.com/docs/dl?topic=dl-how-to-order-ibm-cloud-dl-dedicated).
* Detailed steps (including screenshots) to order Direct Link Connect are available in the [documentation](https://cloud.ibm.com/docs/dl?topic=dl-how-to-order-ibm-cloud-dl-connect)







 Next Steps 

The next step on the deployment journey is:
About HA VNF deployments 

Support for a highly available, highly resilient VNF can be achieved by using the routing mode feature of the IBM Cloud Network Load Balancer (NLB) for VPC. The following use cases illustrate the use of this feature and also include other resources, such as a transit gateway or direct link (depending on the topology of your environment).

The following use cases are not a comprehensive list of supported topologies.



 Use case 1: Private hub and spoke with transparent VNF and spoke-to-spoke traffic 

Figure 1 illustrates a transparent VNF being used within the transit (hub) VPC to process data traffic within the VPC spokes.

The following resources are configured:



* The VPC hub contains the private NLB, which is configured in "Routing mode" and the transparent VNFs are added to its pool to enable HA.
* VPC-spoke#1 contains a private IBM Cloud Application Load Balancer (ALB) for VPC with a pool that contains the workload subnets for zone1 (10.174.0.0/24) and zone2 (10.174.4.0/24).
* VPC-spoke#2 contains a private ALB with a pool that contains the workload subnet for zone1 (10.174.2.0/24).
* A transit gateway manages the interconnections between the hub and spokes.
* IP spoofing on the VNF interface is the next hop in the hub.



A workload in VPC-spoke#1 zone1 that needs to communicate with a workload in VPC-spoke#2 zone1 must traverse the VNF in the VPC-hub. An egress route from the VPC-spoke#1 subnet (10.174.0.0/24) destined for VPC-spoke#2 (10.174.2.0/24) that hops through the VPC-hub NLB (10.175.0.4), allows the outbound traffic to reach its destination. A similar egress route is created on VPC-spoke#2, which allows the response to also traverse VPC-hub.
The enterprise in this tutorial is simulated in the form of another VPC. Connecting this simulated enterprise (actually another VPC) via the Transit Gateway will ensure an experience very close to what you would experience with a Direct Link.



1. Apply the enterprise_link_tf layer:

./apply.sh enterprise_link_tf
2. Run the zone 1 curl tests in the suite my using the -m (markers) flag. Choose the tests marked with curl, lz1 (left zone 1) and rz1 (right zone 1).

Your expected results are: Connectivity within a VPC, transit <-> spoke(s), enterprise <-> transit, spoke(s) <-> spoke(s) pass but enterprise <-> spoke(s) fail.

pytest -m "curl and lz1 and rz1"







 Step 6: Connect Enterprise to Spoke(s) via Transit NFV Firewall-Router 

The incentive for a transit VPC for enterprise <-> cloud traffic is typically to route, inspect, monitor and log network traffic. In this step a firewall-router appliance will be installed in each zone of the transit VPC.



 NFV Router 

Provision the firewall-router appliances. An ingress route table for Transit Gateway has been added to the transit VPC as indicated by the dotted lines. A subnet has been created in each of the zones of the transit VPC to hold the firewall-router.

Zoom

![Firewall](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/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.