vania-janet/multiturn-rag-retrieval-data huggingface dataset:
When you use Transit Gateway with your VMware® solution on VPC, the routing differs slightly between the two networking architectures.

When you use VMware virtual machines (VMs) on VPC subnets architecture, your VMs are attached to VPC subnets and the routing behaves in the same way as with VPC Virtual Servers. The VPC subnets are provisioned from the zone prefix, and when the VPC is attached to a Transit Gateway, the routing works between other VPCs without any required changes. If you are using IANA-registered IP addresses in your VPC, see [Routing considerations for IANA-registered IP assignments](https://cloud.ibm.com/docs/vpc?topic=vpc-interconnectivityrouting-considerations-iana).

Zoom

![Transit Gateway with VMware on VPC](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/vpc-ryo-diagrams-tgw-sub-arch.svg)

Figure 1. IBM Cloud Transit Gateway with VMware on VPC

When you use NSX-T™ on your VMware solution on VPC, the VMs are attached on the NSX-T overlay segments. They use an IP address range or prefix, which is reachable through VPC route that points to the NSX-T Tier-0 private uplink VIP as described in [VMware NSX-T logical routing on VPC](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vpc-ryo-nsx-t-vpc-routing). When you attach the VPC to a Transit Gateway, you must create a VPC prefix that matches the VPC route, which points to the NSX-T overlay. You must not define any subnets on the prefix.
The spoke -> transit traffic can be routed using an egress routing table in the spokes.

Zoom

![Routing traffic from spoke to transit with an egress routing table](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/vpc-transit/vpc-transit-spoke-egress.svg)

Routing traffic from spoke to transit with an egress routing table

In the diagram below this is represented by the egress dashed line.

Zoom

![Egress traffic from spoke](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/vpc-transit/vpc-transit-spoke-egress-hi-fix.svg)

Egress traffic from spoke



1. Apply the spoke_egress_tf layer:

./apply.sh spokes_egress_tf
2. Run the test suite. Your expected results are: All tests pass.

pytest -m "curl and lz1 and (rz1 or rz2)"
3. Visit the [VPCs](https://cloud.ibm.com/vpc-ext/network/vpcs) in the IBM Cloud console. Select one of the spoke VPCs and then click on Manage routing tables click on the Egress routing table. With this change spoke traffic originating in a spoke in Dallas 2 remains in Dallas 2 as it flows through the firewall-router in the transit VPC.
4. Notice these routes in the spoke's egress routing table:



 Zone Destination Next hop 

 Dallas 1 192.168.0.0/16 10.1.0.196 
 Dallas 2 192.168.0.0/16 10.2.0.196
[Sample Direct Link on-premises interconnect use case](https://cloud.ibm.com/docs-content/v1/content/b698ea8660e1f51664f7479f870bbf8840335d06/dl/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

!
* [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 routed all cross VPC traffic through a transit VPC firewall-router. DNS services were created for each VPC. DNS forwarding rules were created between the services for workloads and a virtual private endpoint gateways.





 Remove resources 

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

./apply.sh -d : :





 Expand the tutorial 

Your architecture may not be the same as 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 Logs for VPC 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.
* Replace the worker VSIs with [Red Hat OpenShift on IBM Cloud and VPC load balancer](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaas).
* Force all out bound traffic through the firewall in the transit VPC and through [Public gateways](https://cloud.ibm.com/docs/vpc?topic=vpc-public-gateways) .







 Related content 



* [IBM Cloud for Financial Services](https://cloud.ibm.com/docs/framework-financial-services)
(https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-faq-service-discovery)
* [Do ordering service Raft nodes use Transport Layer Security (TLS) for communication?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-faq-raft-tls)
* [How can I back up and restore components and networks?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-faq-backup-restore)
* [What benefits are available with the new smart contract lifecycle available on nodes and channels running on Fabric v2.x?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-faq-new-lifecycle)
* [How can I check and interpret the status of my components through the Kubernetes command line?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibm-v2-faq-cr-status)



Certificates



* [Do you support using certificates from non-IBM Certificate Authorities (CAs)?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-faq-v2-external-certs)
* [What is the recommended way to manage private keys?](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-faqibp-v2-faq-hsm)
* [Can I integrate my corporate LDAP server with the Certificate Authority (CA) in the IBM Blockchain Platform?]
SC-7 (4) - External Telecommunications Services 



  Control requirements 

The organization:

SC-7 (4) (a)
:   Implements a managed interface for each external telecommunication service;

SC-7 (4) (b)
:   Establishes a traffic flow policy for each managed interface;

SC-7 (4) (c)
:   Protects the confidentiality and integrity of the information being transmitted across each interface;

SC-7 (4) (d)
:   Documents each exception to the traffic flow policy with a supporting mission/business need and duration of that need; and

SC-7 (4) (e)
:   Reviews exceptions to the traffic flow policy [IBM Assignment: at least annually] and removes exceptions that are no longer supported by an explicit mission/business need.





  Implementation guidance 

See the resources that follow to learn more about how to implement this control.



*  [Connecting application provider to the management VPC](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-management)







  Implementation guidance 

See the resources that follow to learn more about how to implement this control.



*  [Connecting application provider to the management VPC](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-management)
* The Edge Node VM requires two host switches:



* nsxHostSwitch overlay - is associated with an overlay transport zone that is shared with the NSX-T ESXi transport nodes and uses the IP pool that was previously configured.
* nsxHostSwitch vlan - is associated with a VLAN transport zone and is used to enable bridging the virtual wire that is connected to this interface to an NSX-T segment.



* The Edge node VM must be part of an Edge cluster. An Edge cluster can consist of a single Edge node VM. If HA is required, deploy two Edge node VMs with the same configuration and add to the cluster.



4. Create NSX-T segments with connectivity turned off while the north-south traffic is being routed through the ESGs in the NSX-V environment. For more information, see [Create the NSX-T Data Center Topology](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/migration/GUID-48287E4C-7C0F-4146-94D4-6D295623E7EB.html). Using NSX-T Manager, create an Edge Bridge Profile associated with the NSX-T Edges nodes. The profile defines the Edge cluster that is used for bridging, the primary node, the (optionally) backup node, and failover policy. Configure the bridging on the required NSX-T segment.
5. The NSX-V logical switch is now bridged to the associated NSX-T logical segment. You can test by deploying a VM on the vCenter Server with NSX-T environment on the bridged segment with an IP address from the subnet that is used on the NSX-V logical switch.







 Network switchover between NSX-V and NSX-T environments 

The network switchover enables all north-south network traffic to and from the migrated VMs to traverse the NSX-T T1 and T0 routers. If issues occur with the north-south connectivity, the gateway can be moved back to the NSX-V environment.

Zoom

!
For more information, see [Influencing route preference using AS prepends](https://cloud.ibm.com/docs/dl?topic=dl-models-for-diversity-and-redundancy-in-direct-linkdl-bgp-path-selection) and [Planning considerations when using AS prepends with VPC connections](https://cloud.ibm.com/docs/dl?topic=dl-as-prepends-routes).





 Direct Link Connect use cases 

These use cases are best for working with hybrid workloads, cross-provider workloads, large or frequent data transfers, private workloads, and environment administration. Use these use cases:



* When you want quicker connectivity for mission-critical workloads.
* When you need connections between a client network and IBM Cloud at speeds of 5 Gbps or less.
* When diverse ports in a point of presence (PoP) are available.





 Direct Link Connect use case 1: Leveraging service provider networks to virtually reach IBM Cloud 

The Direct Link Connect solution enables you to use a service provider to deliver connectivity to IBM Cloud locations. This offering typically provides connectivity at a reduced cost because the physical connectivity from IBM Cloud to the service provider is already in place, which is shared among other customers.

Some benefits include:



* Multi-cloud use through a single Connect port
* Latency tolerant
* Lower cost entry to IBM Cloud



Zoom

![Leveraging service provider networks to virtually reach IBM Cloud](https://cloud.ibm.com/docs-content/v1/content/b698ea8660e1f51664f7479f870bbf8840335d06/dl//images/direct-link-connect.png)

Figure 2. Leveraging service provider networks to virtually reach IBM Cloud





 Direct Link Connect use case 2: Other Cloud Service Providers (CSPs) or enterprises 



* Multicloud use through a single Connect port
* Latency tolerant
* Multi-tenant via NNI between IBM Cloud and a service provider
* Layer 2 and Layer 3 support
* Lower cost of entry to IBM Cloud



Zoom

!
<br>Possible values: Value must match regular expression ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ 
 Request Body <br>Required <br>TransitGatewayConnectionTemplate The connection template 
 network_type <br>Required <br>string Defines the type of network being connected to. For access to gre_tunnel connections, contact IBM support. <br>Allowable values: [classic,directlink,gre_tunnel,unbound_gre_tunnel,vpc] <br>Example:vpc 
 base_connection_id <br>string The ID of an active transit gateway. network_typegre_tunnel connections must be created over an existing network_typeclassic connection. This field is required for gre_tunnel connections and must specify the ID of an active transit gateway network_type classic connection in the same transit gateway. Omit base_connection_id for any connection type other than gre_tunnel. <br>Example:975f58c1-afe7-469a-9727-7f3d720f2d32 
 base_network_type <br>string Defines the type of network the GRE tunnel is targeting. This field is required for, and only applicable to, unbound_gre_tunnel type connections. <br>Allowable value: [classic] <br>Example:classic 
 local_gateway_ip <br>string The local gateway IP address. This field is required for, and only applicable to, gre_tunnel and unbound_gre_tunnel type connections. <br>Example:192.168.100.1 
 local_tunnel_ip <br>string The local tunnel IP address. This field is required for, and only applicable to, gre_tunnel and unbound_gre_tunnel type connections. The local_tunnel_ip and remote_tunnel_ip addresses must be in the same /30 network. Neither can be the network nor the broadcast addresses. <br>Example:192.168.129.2 
 name <br>Name The user-defined name for this transit gateway connection.
Similarly the CIDR 192.168.0.0/24 covers the enterprise and is passed through the Transit Gateway to the spokes as an advertised route.

Egress routes in the spokes route traffic to the firewall-router. Ingress routes in the transit route enterprise <-> spoke traffic through the firewall-router.





 Step 1: Provision initial VPC resources routing all intra VPC traffic through the firewall-router 

Often an enterprise uses a transit VPC to monitor the traffic with the firewall-router. In part one only enterprise <-> spoke traffic was flowing through the transit firewall-router. This section is about routing all VPC to VPC traffic through firewall-router.

This diagram shows the traffic flow implemented in this step:

Zoom

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

Traffic flow

All traffic between VPCs will flow through the firewall-router:



* enterprise <-> spoke.
* enterprise <-> transit.
* transit <-> spoke.
* spoke <-> spoke in different VPC.



Traffic within a VPC will not flow through the firewall.

If continuing from part one make special note of the configuration in the terraform.tfvars: all_firewall = true.



 Apply Layers 



1. 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.
Planning for IBM Cloud Transit Gateway 

Make sure that you review the following considerations before ordering your IBM Cloud® Transit Gateway.



 General considerations 

All prefixes of a VPC and all subnets of a classic network will connect to the transit gateway, so it's important that they do not overlap. When creating VPCs that are intended to connect to a transit gateway, make sure to create the VPCs with non-overlapping VPC prefixes.



* IBM Cloud Transit Gateway supports provisioning transit gateways in the regions listed in [IBM Cloud Transit Gateway locations](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-tg-locations).
* Create your transit gateway in a location that makes sense for your workload. For example, if you are connecting two VPCs in the us-south (Dallas) region and one VPC in the eu-de (Frankfurt) region, creating your gateway in us-south region would be the most efficient for your workload.
* You cannot connect a [classic access VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-setting-up-access-to-classic-infrastructure) directly to a transit gateway. To connect the classic resources, use the IBM Cloud classic infrastructure connection, and then all the resources in your classic access VPC are automatically connected.
* A transit gateway requires at least two connections before network traffic can flow over the transit gateway. Transit gateways that have less than two connections for 45 days or more are subject to be reclaimed (suspended, then deleted after 30 days).
* You can connect a VPC, Direct Link, or classic infrastructure to multiple local gateways and a single global gateway.
* 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.
[Traffic flow](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/includes/solution-tutorials/includes/solution-tutorials/images/solution41-vpc-multi-region/vpc-multi-region-alternatives.svg)

Traffic flow

For more information read through the [Proxying DNS records and global load balancers](https://cloud.ibm.com/docs/cis?topic=cis-dns-conceptsdns-concepts-proxying-dns-records) topic.





 Alternative 1: Proxy, traffic flows through CIS 

This first alternative creates a wildcard certificate for example.com and then proxies it in the IBM Cloud Internet Services (CIS) allowing you to take advantage of industry leading security, protection and performance capabilities.

Currently ordering certificates is by using Let's Encrypt, you may follow the topic [Supported certificate authorities](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-order-certificatesconnect-certificate-authority) for updates. Using Let's Encrypt requires an ACME account. Follow the steps outlined in the [Connecting third-party certificate authorities](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-add-certificate-authority&interface=ui) topic to create or register your account. In addition, you are required to add a DNS provider following the steps in the [Connecting DNS providers](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-add-dns-provider&interface=uiadd-dns-provider-ui) topic. For this tutorial, you must add CIS as your DNS provider.

Initially HTTPS is configured from the user to Secrets Manager only.



1. Order a certificate in Secrets Manager



* Open the Secrets Manager service and select Secrets on the left.
* Click Add and then TLS certificates.
* Click on the Order a public certificate tile.
Why can't my devices communicate with one another on the same private VLAN? 

If each server is on a different subnet, then by default, they are not able to communicate via IP addresses. Technically, your servers can communicate by using OSI Model Layer 2 methods because they are on the same VLAN (a Layer 2 construct). For Internet Protocol (IP) (also called Layer 3) communication to work, you can do either of the following:



* Add a route for the subnet you're attempting to communicate with on each server (the route is different on each server)
* Enable [VLAN Spanning](https://cloud.ibm.com/docs/vlans?topic=vlans-vlan-spanning)



Keep in mind that [VLAN Spanning](https://cloud.ibm.com/docs/vlans?topic=vlans-vlan-spanning) has additional implications, so review the feature in detail before enabling it.





 What options do I have if I need devices on different private subnets within the same VLAN to communicate by default, but I don't want to enable VLAN Spanning? 

If you cannot enable VLAN spanning but require some VLANs and subnets to route between each other, you can associate those VLANs with a firewall or gateway, and manage the routing and security to fit your needs. To route between Pods and data centers, all VLANs requiring connectivity must be associated with the gateway device and an overlay, typically GRE tunnels, established between the gateway devices.
Networking <br><br> * [VPC infrastructure services](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environment)<br> * [Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-cli-plugin-dl-cli)<br> * [Transit Gateway](https://cloud.ibm.com/docs/tg-cli-plugin?topic=tg-cli-plugin-transit-gateway-cli)<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-cli-plugin-ic-cos-cli)<br><br><br> <br><br> * [Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-cli-plugin-ic-cos-cli)<br><br><br> 
 Security <br><br> * [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-cli-plugin-hpcs-cli-plugin)<br><br><br> <br><br> * [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-cli-plugin-hpcs-cli-plugin)<br><br><br> <br><br> * App ID [3]<br><br><br>
Networking <br><br> * [VPC infrastructure services](https://cloud.ibm.com/vpc?topic=vpc-ha-dr-vpc)<br> * [Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-ha-dr)<br> * [Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-ha-drdisaster-recovery)<br><br><br> 
 Storage <br><br> * [Block Storage for VPC](https://cloud.ibm.com/vpc?topic=vpc-ha-dr-vpc)<br> * [Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpointsendpoints-geo)<br><br><br> <br><br> * [Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpointsendpoints-geo)<br><br><br> 
 Security <br><br> * [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-ha-drcross-region-disaster-recovery)<br><br><br> <br><br> * [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-ha-drcross-region-disaster-recovery)<br><br><br> <br><br> * [App ID](https://cloud.ibm.com/docs/appid?topic=appid-ha-dr)<br><br><br>