vania-janet/multiturn-rag-retrieval-data huggingface dataset:
When the transit_encryption property set to user_managed, encryption in transit with an instance identity certificate is enabled. The default is none, which disables encryption in transit. The default access control mode is security_group, which is shown in the response.

curl -X POST "$vpc_api_endpoint/v1/shares?version=2023-05-11&generation=2&maturity=beta" 
-H "Authorization: $iam_token" 
-d '{
"size": 10,
"name": "myshare-1",
"profile": {
"name": "dp2"
},
"zone": {
"name": "us-south-1"
},
"mount_targets": [
"virtual_network_interface": {
"subnet": {
"id": "4e95744c-7e64-48c9-b5d2-3b6481b1dfde"
},
},
"transit_encryption": {
"user_managed"
}
]
}'
Show more

A successful response looks like the following example.

{
"access_control_mode": "security_group",
"created_at": "2023-05-11T12:15:12Z",
"href": "$vpc_api_endpoint/v1/shares/90c4bb62-1724-47bd-8c45-f7d37d7c3508/mount_targets/7e5bdb52-676d-43b2-991f-2053cf6855eb",
"id": "7e5bdb52-676d-43b2-991f-2053cf6855eb",
"lifecycle_state": "pending",
"mount_path": "",
"name": "myshare-1",
"primary_ip": {
: The existing name or ID of the route.

--name ROUTE_NAME
: The updated name to be given to the route (optional).

Do not include any personal identifying information (PII) in any resource names.

--file RULES_DEFINITION_JSON_FILE
: A JSON file that contains the definition of the rules for route. The file needs to be formatted as follows:

[
{
"targets": {"id":"ID1"},{"id":"ID2"}]
}
]

Where targets is a comma-separated list of target IDs.

The rule definition can optionally also include inclusion filters. For example,

[{
"action": "send",
"targets": {
"id":"11111111-1111-1111-1111-111111111111"
}],
"inclusion_filters":
{
"operand": "service_name",
"operator": "in",
"values":
"appconnect",
"cloudant",
"containers-kubernetes"
]
},
{
"operand": "location",
"operator": "in",
"values":
"us-south",
"eu-de"
]
}
]
}]
Show more

Where:

action
: Action defines whether IBM Cloud® Metrics Routing includes or excludes metrics on the route. Two actions are supported: send and drop. If not specified, the default action is to send the metrics.

send
: Metrics are sent, based on the routing rule, on the defined route.

drop
: Metrics are excluded, based on the routing rule, when metrics are sent on the defined route.

operand
: Operand is the name of the property on which the operator test is run.
Category VPC reference architecture Satellite reference architecture Optional for both 

 Core <br><br> * [VPC infrastructure services](https://cloud.ibm.com/vpc?topic=vpc-ha-dr-vpc)[1]<br><br><br> <br><br> * [Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-ha)<br><br><br> 
 Containers <br><br> * [Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-ha)<br> * [Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-ha-dr)<br><br><br> <br><br> * [Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-ha)[2]<br> * [Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-ha-dr)<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-drhigh-availability)<br><br><br>
For more information, see [NSX-V to NSX-T migration tools](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-v2t-l2-nsx-t).



If the configurations are simple, or there are not too many rules or definitions, manual, or scripted is typically the simplest way to migrate the configuration. If the configurations are complex, consider the use of a third-party tool.

Migration Coordinator supports other migration approaches such as "in-place migration", which is not supported in IBM Cloud®. Therefore, consider the documentation at [NSX-V to NSX-T 3.x Migration Coordinator](https://nsx.techzone.vmware.com/resource/nsx-v-nsx-t-3x-migration-coordinator_Toc57645169).



 Understanding-distributed firewall complexity 

It is important to understand the complexity of your distributed firewall configuration.



* If you are not using distributed firewall, then you must not migrate the configuration.
* If in your distributed firewall configuration "Applied To" is set to "DFW" and all the rules are IP-based, then by migrating workload virtual machines is a single stage process.
* If in your DFW configuration has the following, then a multistage approach for workload VMs is needed:



* If "Applied To" is set to "DFW" in all the rules, and there are rules with Security Groups with dynamic memberships based on Security Tags or with static memberships.
* If "Applied To" is set to a universal security group or a universal logical switch in any rule. Also, if there are rules with Security Groups with dynamic memberships based on Security Tags or with static memberships.
* If "Applied To" is set to a universal security group or a universal logical switch in any rule, and all the rules are IP-based.









 Distributed firewall migration guidance 

When you migrate the workload VMs to the NSX-T environment in waves, it is imperative that the distributed firewall does not break communications between the workload VMs during the migration.
The different types of subnets and how they operate is further detailed in [Subnets and IPs](https://cloud.ibm.com/docs/subnets?topic=subnets-getting-started).





 Communication within a VLAN 

All resources on a VLAN can communicate, but that does not mean they will by default. Remember that VLANs are an OSI Model layer 2 construct, and that subnet/IPs are a layer 3 construct. Communication happens differently at each layer. Resources in different VLANs, whether on the public or private network, cannot communicate with one another via layer 2 methods.



 Communication within a VLAN on the public network 

Communication between resources on the public network is not inherently restricted, whether on one or more VLANs within IBM Cloud's public network infrastructure or the internet. Restrictions can be added by introducing a firewall or gateway appliance.





 Communication within a VLAN on the private network 

By default, only compute within the same subnet can communicate, even if multiple subnets are in the same VLAN. However, it is possible to communicate with other subnets on the same VLAN, provided that the compute instances have route entries for the additional subnets on that VLAN. Managing route entries on all compute nodes that need to communicate across private subnets can be cumbersome. See [VLAN spanning](https://cloud.ibm.com/docs/vlans?topic=vlans-vlan-spanning) for how to handle situations where default communication is required among all compute within the same VLAN. Review VLAN spanning carefully before enabling, because it has broad implications.
* Can I transfer portable subnet IP addresses between servers?

Yes. When transferring an IP address from one server to another, make sure that a gratuitous ARP packet is sent. This action allows IBM Cloud's routers to update the ARP entry and forward traffic to the correct server. Not doing so might result in up to a 4-hour delay in the new server receiving traffic for the transferred address.



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/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.
* "destination_field" : string - required - The name of the container object where enrichments are created.

Field names defined in your configuration must meet the restrictions defined in [Field Name Requirements](https://cloud.ibm.com/docs/discovery?topic=discovery-configreffield_reqs).





 Element Classification enrichments 

The Element Classification enrichment is deprecated and will no longer be available, effective 10 July 2020.

When you use the Element Classification, each elements enrichment object must contain an "options": {} object with the following parameters specified:



* "model" : string - required - The element extraction model to be used with on this document. Currently supported models are: contract



When you use the elements enrichment, it is important to follow the guidelines specified in [Element Classification](https://cloud.ibm.com/docs/discovery?topic=discovery-element-classification). Specifically, only PDF files can be ingested when this enrichment is specified.





 Natural Language Understanding enrichments 

When you use the Natural Language Understanding, each object within the enrichments array must also contain an "options": { "features": { } } object that contains one or more of the following enrichments:





 categories 

The categories enrichment identifies any general categories in the ingested document. This enrichment has no options and must be specified as an empty object "categories" : {}





 concepts 

The concepts enrichment finds concepts with which the input text is associated, based on other concepts and entities that are present in that text.



* "limit" : INT - required - The maximum number of concepts to extract from the ingested document.







 emotion 

The emotion enrichment evaluates the overall emotional tone (for example anger) of entire document or specified target strings in the entire document. This enrichment can only be used with English content.



* "document" : booleanoptional - When true the emotional tone of the entire document is evaluated.
* "targets" : arrayoptional - A comma-separated array of target strings of which to evaluate the emotional state within the document.







 entities 

The entities enrichment extracts instances of known entities such as people, places, and organizations.
This example illustrates the response from creating an unbound GRE tunnel:

{
"created_at": "2020-03-31T12:08:05Z",
"id": "1a15dca5-7e33-45e1-b7c5-bc690e569531",
"name": "example-connection",
"network_type": "unbound_gre_tunnel",
"base_network_type": "classic",
"status": "pending",
"updated_at": "2020-03-31T12:08:05Z"
}

For more information (including Java, Node, Python and Go examples), refer to [Add Connection to a Transit Gateway](https://cloud.ibm.com/apidocs/transit-gatewaycreate-transit-gateway-connection).









 Creating a Generic Routing Encapsulation tunnel connection using Terraform 

You can specify the following argument references for your resource when creating an unbound Generic Routing Encapsulation (GRE) tunnel connection:



Table 5. Terraform argument references for creating a GRE

 Argument Details 

 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 name of the connection. If the name is not given, the default name is provided based on the network type, such as unbound_gre_tunnel for network type unbound gre. 
 network_type <br>Required <br>Forces new resource <br>string The network type.
For more information, see [API version comparison](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-migrate-to-v2-api).



* v2 organizes data by project and collections; there is no concept of an environment. For example, compare the following requests to get a collection:

v1 [Get collection](https://cloud.ibm.com/apidocs/discoverygetcollection)

GET {url}/v1/environments/{environment_id}/collections/{collection_id}

v2 [Get collection](https://cloud.ibm.com/apidocs/discovery-datagetcollection)

GET {url}/v2/projects/{project_id}/collections/{collection_id}
* In v1, relevancy training runs on a single collection. In v2, relevancy training runs on a project. The project might contain many collections. If so, relevancy training is applied across all of the collections. For information about how to transfer relevancy training, see [Transferring relevancy training](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-migrate-to-v2migrate-to-v2-transfer-relevance).

For example, compare the following requests that return the status of relevancy training:

v1 [Get collection](https://cloud.ibm.com/apidocs/discoverygetcollection)

GET {url}/v1/environments/{environment_id}/collections/{collection_id}

v2 [Get project](https://cloud.ibm.com/apidocs/discovery-datagetproject)

GET {url}/v2/projects/{project_id}
* Submitting a query is similar between the two versions. In v2, you can query all of the collections in a project or you can limit the query to one or more collections by specifying a collection_ids parameter. For example, compare the following requests to query data:
Architecture pattern for using Transit Gateway with a vCenter Server with NSX-T instance 

This architecture pattern presents hybrid cloud connectivity by using [IBM Cloud® Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-about). This solution is applicable for NSX-T based vCenter Server instance, which is provisioned in IBM Cloud classic infrastructure. This pattern requires a [gateway appliance](https://cloud.ibm.com/docs/gateway-appliance?topic=gateway-appliance-about) or [gateway cluster](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_orderinginstance-addl-clustersvc_orderinginstance-addl-clusters-gate) with Juniper vSRX or other third-party device, which supports GRE. In this solution, GRE tunnel is established between this device and Transit GW Router in a specific Zone. NSX-T T0 advertises routes through vSRX (or other device) to Transit Gateway.



 Deploying Transit Gateway with vCenter Server and NSX-T 

The following diagram presents an overview for an architecture pattern for deploying Transit Gateway with vCenter Server and NSX-T.

Zoom

![Transit Gateway with vCenter Server and NSX-T](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-vcs-nsx-t-transit-gw.svg)

Figure 1. Transit Gateway with vCenter Server and NSX-T

The following list summarizes the architecture pattern deployment:



1. vCenter Server instance is deployed at IBM Cloud Classic Infrastructure. Two IBM Cloud private VLANs and one IBM Cloud Public VLAN (optional) is deployed. Each of them hosts multiple subnets. You can see the details through IBM Cloud for VMware Solutions portal.
2.
Setting Transport Layer Security (TLS) options 

The Transport Layer Security (TLS) options let you control whether visitors can browse your website over a secure connection, and when they do, how IBM Cloud® Internet Services connects to your origin server.

Use the latest version of the TLS protocol (TLS 1.3) for improved security and performance by switching from Off to On.



 TLS encryption modes 

Set the TLS mode by selecting one of the following options from the Mode list.

These options are listed in the order from the least secure (Off) to the most secure (End-to-End CA signed).



* [Off](https://cloud.ibm.com/docs/cis?topic=cis-cis-tls-optionstls-encryption-modes-off) (not recommended)
* [Client-to-Edge](https://cloud.ibm.com/docs/cis?topic=cis-cis-tls-optionstls-encryption-modes-client-to-edge) (edge to origin not encrypted, self-signed certificates are not supported)
* [End-to-End flexible](https://cloud.ibm.com/docs/cis?topic=cis-cis-tls-optionstls-encryption-modes-end-to-end-flexible) (edge to origin certificates can be self-signed)
* [End-to-End CA signed](https://cloud.ibm.com/docs/cis?topic=cis-cis-tls-optionstls-encryption-modes-end-to-end-ca-signed) (default and recommended)
* [HTTPS only origin pull](https://cloud.ibm.com/docs/cis?topic=cis-cis-tls-optionstls-encryption-modes-origin-only-pull) (Enterprise only)





 Off 

No secure connection between your visitor and CIS, and no secure connection between CIS and your web server. Visitors can only view your website over HTTP, and any visitor attempting to connect using HTTPS receives an HTTP 301 Redirect to the plain HTTP version of your website.

Zoom

!
* vMotion address Maintaining a separate network for vMotion is a common practice in the on-premises data center. The Cloud Gateway must have access to the vMotion network. If it does not, an extra IP address is needed to communicate with the vMotion network.
* On-premises



* One IP address for the HCX Connector appliance.
* One for each HCX-IX Interconnect Appliance, add one for a separate vMotion network (if applicable).
* One for each HCX Network Extension Virtual Appliance.



* IBM Cloud



* Two IP addresses per HCX Connector appliance connected to IBM Cloud. The addresses can be used to connect to the internet or one or more IBM Cloud Direct-Link connections.
* Add one for a separate vMotion network connection (if applicable).









 Proximity routing 

Proximity routing is a networking feature that can be enabled when the HCX-IX is configured. Proximity routing is only available with NSX-V target.

After 21 June 2022, provisioning new vCenter Server instances with NSX–V is no longer supported. However, you can add hosts and clusters to your existing NSX–V deployments. IBM strongly recommends that clients immediately assess their NSX–V networks and plan a much earlier migration to NSX–T.

Proximity routing ensures forwarding between VMs that are connected to stretched and routed networks, both on-premises and in the cloud, is symmetrical. This feature requires Dynamic Routing to be configured between the customer premises and the cloud.

When users extend their networks to the cloud, Layer 2 connectivity is stretched onto IBM Cloud. However, without route optimization, Layer 3 communication requests must return to the on-premises network origin to be routed. This return trip is called tromboning or hairpinning.

Tromboning is inefficient because packets must travel back and forth between the network origin and the Cloud, even when both the source and destination VMs are in the Cloud. In addition to inefficiency, if the forwarding path includes stateful firewalls, or other inline equipment that must see both sides of the connection, communication might fail.
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 

Transit Gateway route reports
: You can now request a route report, which shows all routes known to a transit gateway and each of its connections. The report shows:



* Border Gateway Protocol (BGP) information associated with these routes
* Which connections supply which routes
* Overlapping routes



: For more information, see [Generating a transit gateway route report](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-route-reports).





 30 August 2021 

Direct Link connections for transit gateways
: Transit gateways now support Direct Link connections. A Direct Link connection allows an on-premises network to connect to other networks (for instance, VPC and classic infrastructure) that are connected to the same transit gateway.
: The beta release has ended. If you participated in this beta, you can continue to use the gateways that you created during the beta period.





 17 June 2021 

Allow Generic Routing Encapsulation (GRE) connections for transit gateways
: Transit gateways now support connections using GRE tunnels to connect endpoints. 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.
Core <br><br> * [VPC infrastructure services](https://cloud.ibm.com/docs/vpc?topic=ibm-cloud-provider-for-terraform-getting-started)[9]<br><br><br> <br><br> * [Satellite](https://cloud.ibm.com/docs/openshift?topic=openshift-terraform-setup)<br><br><br> 
 Containers <br><br> * [Red Hat OpenShift on IBM Cloud](https://github.com/terraform-ibm-modules/terraform-ibm-cluster/tree/master/examples/secure-roks-cluster)<br> * [Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_terraform-setup&interface=ui)<br><br><br> <br><br> * [Red Hat OpenShift on IBM Cloud](https://github.com/terraform-ibm-modules/terraform-ibm-cluster/tree/master/examples/secure-roks-cluster)[10]<br> * [Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_terraform-setup&interface=ui)<br><br><br> 
 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>