vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* For VPC connections to a direct link, you "can" use restricted Classic IP ranges in the 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15, and 10.254.0.0/16 blocks.
* For direct links connected to transit gateways, these IP ranges are always filtered to protect classic networks that could potentially be connected to transit gateways.



* A Generic Routing Encapsulation (GRE)/IPsec tunneling requirement between your Edge router and a customer virtual router in IBM Cloud requires a non-conflicting subnet when ordering. Default addresses for Direct Link are non-routable and do not support tunneling.
* 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. When using IANA-registered ranges within your enterprise, and within VPCs in conjunction with IBM Cloud Direct Link, custom routes must be installed in each zone. For more information, see [Routing considerations for IANA-registered IP assignments](https://cloud.ibm.com/docs/vpc?topic=vpc-interconnectivityrouting-considerations-iana).
* If you plan to connect your direct link to a transit gateway, keep in mind that a single direct link instance accepts a maximum of 120 on-premises address prefixes when connected to a transit gateway. Consider aggregating prefixes to keep within this limit. (A direct link can accept a maximum of 200 prefixes when not connected to a transit gateway.)
* For known limitations and restrictions, see [Known limitations](https://cloud.ibm.com/docs/dl?topic=dl-known-limitations).







 Partner-specific instructions 



* [AT&T NetBond for Cloud](https://cloud.ibm.com/docs/dl?topic=dl-netbond)
* [AT&T NetBond Essentials via Equinix Fabric](https://cloud.ibm.com/docs/dl?topic=dl-att-netbond-essentials)
* [Enabling TCP health checks for UDP load balancers](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaasvpc_lb_health_udp)



* [Changing load balancer subnets or zones](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaaslbaas_change_subnets)
* [Limitations](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaaslbaas_limitations)



[Classic: About network load balancers (NLBs)](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-aboutloadbalancer-about)



* [Comparison of basic and DSR load balancing in version 1.0 and 2.0 NLBs](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-aboutcomparison-lbs)
* [Components and architecture of an NLB 1.0](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-aboutv1_planning)



* [Traffic flow in a single-zone cluster](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-aboutv1_single)
* [Traffic flow in a multizone cluster](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-aboutv1_multi)



* [Components and architecture of an NLB 2.0](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-aboutplanning_ipvs)



* [Traffic flow in a single-zone cluster](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-aboutipvs_single)
* [Traffic flow in a multizone cluster](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-aboutipvs_multi)
It is referenced only when you configure the routes on the Vyatta.

set interfaces vti vti1 description "to-IBM-VPN-primary"
set interfaces vti vti1 address 169.254.0.2/30
set interfaces vti vti1 ip tcp-mss limit 1360
set security vpn ipsec site-to-site peer {{ primary_peer_address }} authentication mode pre-shared-secret
set security vpn ipsec site-to-site peer {{ primary_peer_address }} authentication pre-shared-secret {{your_pre_shared_key}}
set security vpn ipsec site-to-site peer {{ primary_peer_address }} ike-group ibm-vpc-ike-group
set security vpn ipsec site-to-site peer {{ primary_peer_address }} default-esp-group ibm-vpc-ipsec-group
set security vpn ipsec site-to-site peer {{ primary_peer_address }} description "to-IBM-VPN-primary"
set security vpn ipsec site-to-site peer {{ primary_peer_address }} local-address {{ vyatta_address }}
set security vpn ipsec site-to-site peer {{ primary_peer_address }} connection-type initiate
set security vpn ipsec site-to-site peer {{ primary_peer_address }} authentication remote-id {{ primary_peer_address }}
set security vpn ipsec site-to-site peer {{ primary_peer_address }} vti bind vti1
Show more
4. Create the primary route:

set protocols static route {{ ibm_vpc_cidr }} next-hop 169.254.0.1 distance 10
set protocols static route {{ ibm_vpc_cidr }} next-hop 169.254.0.1 interface vti1
5. Create the VTI and VPN connection to the IBM secondary tunnel:

set interfaces vti vti2 description "to-IBM-VPN-secondary"
For more information (including Java, Node, Python and Go examples), see "Add Connection to a Transit Gateway" in the [Transit Gateway API reference](https://cloud.ibm.com/apidocs/transit-gateway?code=javacreate-transit-gateway-connection).









 Adding a connection using Terraform 

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



Table 5. Terraform argument references for creating a connection

 Argument Details 

 base_connection_id <br>Optional <br>Forces new resource <br>string The ID of a network_type 'classic' connection a tunnel is configured over. <br>This field only applies to network type gre_tunnel connections. 
 base_network_type <br>Optional <br>Forces new resource <br>string The base network type. Allowed values are classic. <br>This field only applies to unbound_gre_tunnel type connections. 
 gateway <br>Required <br>Forces new resource <br>string Enter the transit gateway identifier. 
 local_gateway_ip <br>Optional <br>Forces new resource <br>string The local gateway IP address. <br>This field is required for, and only applicable to, gre_tunnel and unbound_gre_tunnel type connections. 
 local_tunnel_ip <br>Optional <br>Forces new resource <br>string The local tunnel IP address. <br>This field is required for, and only applicable to, gre_tunnel and unbound_gre_tunnel type connections. 
 name <br>Optional <br>string The connection name. If the name is not given, a default name is provided based on the network type, such as vpc for network type VPC and classic for network type classic. 
 network_account_id <br>Optional <br>Forces new resource <br>string The ID of the network connected account. This is used if the network is in a different account than the gateway. 
 network_type <br>Required <br>Forces new resource <br>string The network type.
"tcp://1.2.3.4:22",
"tcp://1.2.3.4:23",
"tcp://1.2.3.4:24"
] ! ! ,
"proxy_protocol": false,
"ip_firewall": false,
"edge_ips": {
"type": "dynamic",
"connectivity": "all"
},
"tls": "full",
"traffic_type": "direct"
}

{
"protocol": "tcp/22",
"dns": {
"type": "CNAME",
"name": "glb.example.com"
},
"origin_dns": {
"name": "name-to-glb.example.com"
},
"origin_port": 22,
"proxy_protocol": false,
"ip_firewall": false,
"edge_ips": {
"type": "dynamic",
"connectivity": "all"
},
"tls": "full",
"traffic_type": "direct"
}
Show more
-s, --json-str: Deprecated. The JSON data describing a range application.-j, --json-file: Deprecated. A file contains input JSON data.-i, --instance: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set INSTANCE is used.--output: Specify output format, only JSON is supported.<-- </section "id="section-create-range-app-options" "> --><-- <section "id="section-create-range-app-examples" "> --> Examples Create a range app for doamin 31984fea73a15b45779fa0df4ef62f9b.
"network_id": "crn:v1:bluemix:public:is:us-south:a/123456::vpc:4727d842-f94f-4a2d-824a-9bc9b02c523b",
"network_type": "vpc",
"prefix_filters": [
{
"action": "permit",
"ge": 0,
"le": 32,
"prefix": "192.168.100.0/24"
}
],
"prefix_filters_default": "permit",







 Response 

The following response details show once you initiate the request:



Table 3. Initiate request response

 Response Body Details 

 name <br>Always included* <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]-[a-zA-Z][a-zA-Z0-9])$. <br>Example:Transit_Service_BWTN_SJ_DL 
 network_type <br>Always included* <br>string Defines what type of network is connected via this connection. The list of enumerated values for this property may expand in the future. Code and processes using this field must tolerate unexpected values. <br>Possible values: [classic, directlink, vpc] <br>Example:vpc 
 id <br>Always included* <br>string The unique identifier for this Transit Gateway Connection <br>Example:1a15dca5-7e33-45e1-b7c5-bc690e569531 
 created_at <br>Always included* <br>date-time The date and time that this connection was created 
 network_id <br>string The ID of the network being connected via this connection. This field is required for some types, such as vpc and directlink.
curl -X POST "https://transit.cloud.ibm.com/v1/transit_gateways/test/connections?version=2022-01-27" -H "accept: application/json" -H "Content-Type: application/json" -d "{"base_connection_id":"975f58c1-afe7-469a-9727-7f3d720f2d32","local_gateway_ip":"192.168.100.1","local_tunnel_ip":"192.168.129.2","name":"Transit_Service_BWTN_SJ_DL","network_type":"gre_tunnel","remote_bgp_asn":65010,"remote_gateway_ip":"10.242.63.12","remote_tunnel_ip":"192.168.129.1"}"

{
"base_connection_id": "975f58c1-afe7-469a-9727-7f3d720f2d32",
"local_gateway_ip": "192.168.100.1",
"local_tunnel_ip": "192.168.129.2",
"name": "Transit_Service_BWTN_SJ_DL",
"network_type": "gre_tunnel",
"remote_bgp_asn": 65010,
"remote_gateway_ip": "10.242.63.12",
"remote_tunnel_ip": "192.168.129.1"
}







 Response 

The following response results show once you initiate the request:



Table 3. Initating request response

 Response body Details 

 name <br>Always included* <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] 
 network_type <br>Always included* <br>string Defines what type of network is connected via this connection.
Migration planning 

Migration planning and preparation are the key to a successful migration project. It is imperative that the migration complexity is fully understood so that timescales, required tools, skills, and knowledge are available. An overview migration flow is shown in the following diagram.

Zoom

![Migration flow](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/v2t-diagrams-tree.svg)

Figure 1 Migration flow



 Classify migration complexity 

In the initial stage, the complexity of the migration is estimated. An aspect of this complexity is based on the source environment. Therefore, a review of the current NSX-V environment must be undertaken and documented so the following details are understood:



* Logical network topology - A series of diagrams that document the external and internal networking.
* Logical networking and security configurations - Detailed parameters that are used in the configuration of the NSX-V network and security. Logical switches, routing, distributed firewall, edge firewall, NAT, VPNs, and load balancing are included.
* Clusters and hosts - Information on the clusters and their hosts.
* Workload virtual machines - Placement of VMs, and their relationships to each other.
* Integration - External tools that integrate with vCenter or NSX-V Manager, such as Veeam®, VMware Aria® Operations™ Manager, VMware Aria® Automation™, custom scripts, and other tools.



The following factors govern the complexity of migration:



* Project-based factors - such as how is the project that is being staffed.
* Architecture factors - such as changes to the existing NSX-V environment since deployment.
* Micro-segmentation factors - such as the use of distributed firewall rules and the use of tagging in these rules.
* Integration factors - what systems are integrating with NSX-V Manager and vCenter as both these components are replaced in the migration.
* [Configuring when an ALB can pass a request](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsproxy-next-upstream)
* [Rate limiting](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsrate-limiting)
* [Removing the response header](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsresponse-header-removal)
* [Rewriting paths](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsalb-rewrite-paths)
* [Customizing server block configurations](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsserver-snippets-custom)
* [Routing incoming network traffic](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationssession-affinity-cookies)
* [Allowing SSL services support to encrypt traffic](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsssl-services-support)
* [Accessing apps with non-standard TCP ports](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationstcp-ports-non-standard)
* [Setting a maximum number of upstream keepalive requests](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsupstream-keepalive-requests)
* [Setting the maximum upstream keepalive timeout](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsupstream-keepalive-timeout)
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/b698ea8660e1f51664f7479f870bbf8840335d06/dl/includes/vpc/includes/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.
Layer 7 load balancing 

The IBM Cloud® Load Balancer service distributes traffic among multiple server instances, including bare-metal and virtual-server instances, by using Layer 7 (application layer) data.



*  The data traffic to be distributed is classified by using policies and rules.
*  Policies define what action to take when the data traffic matches all the rules that are associated with a policy.
*  Layer 7 (L7) load balancing is supported for HTTP and HTTPS traffic only.





  Layer 7 policies and rules 

A Layer 7 policy is associated with a front-end application port. Multiple policies can be associated with a front-end port.



*  These policies are evaluated in order, based on the priority assigned to each policy.
*  An associated action is taken when the policy is matched.
*  Each L7 rule is associated with a policy.
*  If all the rules that are associated with the policy evaluate to true, the policy is matched, so the associated action is taken.



For more information, see [L7 Policy and Rules](https://cloud.ibm.com/docs/loadbalancer-service?topic=loadbalancer-service-layer-7-policy).





  Layer 7 pools 

Each Layer 7 load balancer pool contains one or more logical server instances.



*  Each logical server instance is identified by an IP address and port number.
*  Each pool has a health monitor associated with it, which monitors the health of all the servers in the pool.
*  A pool can be configured for session persistence.
*  Use the source IP address of the client or HTTP cookie to configure session persistence.



For more information, see [L7 Pools](https://cloud.ibm.com/docs/loadbalancer-service?topic=loadbalancer-service-layer-7-pool).
For more information, see [Dealing with overlapping VPC prefixes and classic infrastructure subnets](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-troubleshootingoverlapping-vpc-prefixes-and-classic-subnets).







 Interconnectivity patterns 

IBM Cloud Transit Gateway enables you to connect IBM Cloud VPCs and classic infrastructure to transit gateways, allowing you to build global networks of multiple VPCs and classic infrastructure resources across IBM Cloud regions to keep up with your business needs. IBM Cloud Transit Gateway works across IBM Cloud VPCs as well as IBM classic networks.

IBM Cloud Transit Gateway can connect to classic networks located in any MZR, regardless of the location of the transit gateway or the routing type specified.

Here are some ways that you can implement the IBM Cloud Transit Gateway service.



 Use case 1: Interconnect two or more VPCs in the same MZR 

Connect two VPCs in the same region with a local transit gateway.

Zoom

![Connect two or more VPCs in the same MZR](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/images/TGW_SameRegion.png)

Figure 1. Connect two or more VPCs in the same MZR





 Use case 2: Interconnect two or more VPCs across multiple MZRs 

Connect VPCs in multiple regions using a global transit gateway.

Zoom

![Connect two or more VPCs across multiple MZRs](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/images/TGW_Multi-Multi.png)

Figure 2. Connect two or more VPCs across multiple MZRs





 Use case 3: Interconnect one or more VPCs in the same MZR and an IBM classic network
FAQs for IBM Cloud Transit Gateway 

These frequently asked questions can help you when working with the IBM Cloud® Transit Gateway.



 What are the differences between IBM Cloud Transit Gateway and IBM Cloud Direct Link? 

[IBM Cloud Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl) provides connectivity from an external source into a customer's IBM Cloud private network. IBM Cloud Transit Gateway provides connectivity between resources within a customer's IBM Cloud private network.





 Where can I find Transit Gateway pricing? 

You can estimate the cost of a transit gateway using the cost estimator on the provisioning page for IBM Cloud Transit Gateway Transit Gateway. For example, from the [IBM Cloud console](https://cloud.ibm.com/login), click the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) from the upper left and select Interconnectivity > Transit Gateway. Then, click Create transit gateway to open the provisioning page.





 If I connect a classic connection to a transit gateway provisioned with local routing, does that mean I can only communicate with classic infrastructure resources that are in the same location as the transit gateway? 

A classic connection allows you to communicate with all of your global classic infrastructure resources across MZRs, even if it is connected to a transit gateway provisioned with local routing.

The routing option that you choose for a transit gateway only determines what VPCs you can connect to it. Local routing restricts you to connecting VPCs in the same MZR as the transit gateway, while global routing allows you to connect any VPC across the MZRs. Select the routing option that is right for your applications - pricing is changed accordingly.





 Can I create more than one transit gateway in my account? 

You can create more than one transit gateway in your account. Each transit gateway (and its connections) are logically isolated from your other transit gateways.





 Can I create more than two connections for a given transit gateway?
SC-8 (1) - Cryptographic or Alternate Physical Protection 



 Control requirements 

SC-8 (1) - 0
: The information system implements cryptographic mechanisms to [IBM Assignment: prevent unauthorized disclosure of information] during transmission unless otherwise protected by [IBM Assignment: none].





 Additional IBM Cloud for Financial Services specifications 



* The organization must encrypt customer data in transit regardless of the transport mechanism and/or digital media type used, except in the cases of DNS, NTP, BGP, ICMP, ARP, DHCP, TFTP, NFS v3, heartbeat, SNMP read-only, and logging (such as rsyslog/fluentd) traffic assessed as very low risk from a confidentiality/integrity standpoint. For web-based applications, the organization will ensure that transmitted data is protected in accordance with the recommendations of the Open Web Application Security Project (OWASP).







 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)
* [Consumer connectivity to workload VPC](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-workload)
* [Creating and connecting the management and workload VPCs](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-create-vpcs)
* [Data encryption in transit](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-in-transit)







 IBM Cloud for Financial Services profile 

The rules related to this control that follow are part of the IBM Cloud for Financial Services v1.2.0 profile in [IBM Cloud® Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-getting-started).



* Check whether App ID email dispatchers are using HTTPS only
I understand the risks and approve the change. Please reply with the scheduled window(s) of time where this change will be made so we can prepare for the migration."





Migration is completed by the IBM Cloud Network Engineering team. No other information is required from you, except an agreed-to schedule. Typically, packet loss might last 15 - 30 minutes, depending on the complexity of your account. It might be longer if your account has legacy Direct Link connections.







 Limitations 



* Only private networks (also known as backend networks) in classic infrastructure can be connected to your VPC.
* Only subnets allocated to your classic infrastructure with IBM Cloud provisioning systems can be connected to your VPC.
* Only one VPC per region can be enabled for classic access.
* All classic access VPCs must have globally unique address prefixes that do not overlap.
* If your classic infrastructure includes an imported default route from Direct Link, the imported default route is used by your Classic Access VPC. In this scenario, the public gateway and floating IPs in your Classic Access VPC do not provide internet access. When the default route is no longer imported via Direct Link, then public gateways and floating IPs once again provide internet access.