vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Onboarding to the IBM Cloud catalog 

The IBM Cloud catalog lists IBM and third-party services and software that a user can create. As an application provider from a technology vendor, you are encouraged to onboard your offering to the catalog.

You do not need to be [IBM Cloud for Financial Services Validated](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutbecoming-fs-validated) to be listed in the catalog. If you have potential consumers who do not require the Financial Services Validated designation, being listed in the catalog enables you to market to those consumers while you're working toward becoming Financial Services Validated.

To onboard to the IBM Cloud catalog, follow the guidance for services or software.



*  [Getting set up to sell services](https://cloud.ibm.com/docs/sell?topic=sell-get-started)
*  [Getting set up to sell software](https://cloud.ibm.com/docs/sell?topic=sell-sw-getting-started)





  Next steps 

If you plan to provide SaaS:



*  Review [Best practices for software as a service](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practices), which represents a generic set of implementation principles that apply to SaaS applications on both reference architectures.
*  Explore the reference architectures and deployment guidance:



*  [IBM Cloud VPC](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-about)
*  [IBM Cloud for VMware Regulated Workloads](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vmware-overview)





If you plan to provide software that another organization operates:



*  Review [Best practices for software](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practices-software)
Using VRF, IBM Cloud tenants are allowed to use remote IP addresses that normally would not be allowed to overlap in the Global table. When accessing VPC only, IBM still reserves the following RFC 1918, link-local addresses, and multicast addresses, which are not routable from this VRF service:



* 169.254.0.0/16
* 224.0.0.0/4
* 166.9.0.0/16 ( used by the private endpoint service)
* Any IP ranges assigned to your VLANs on the IBM platform.



The following ranges are now available with IBM Cloud Direct Link:



* 10.0.0.0/14
* 10.200.0.0/14
* 10.198.0.0/15



IBM is moving forward with a next-generation Cloud deployment to enable Virtual Private Cloud (VPC) in our availability zones (AZs). This new VPC capability enables Bring-Your-Own-IP (BYoIP) in the VPC-enabled AZs, which are located in Dallas, Washington DC, London, Frankfurt, Tokyo, and Sydney.

For example, each tenant on the backbone who uses VRF can have only one customer VRF per Direct Link, which provides connectivity among all the tenant’s servers, regardless of location. However, an IBM Cloud tenant might have more than one Direct Link account that feeds into a single cross-connect router.



* A tenant’s servers in any VLAN, in any pod, in any data center worldwide can reach all of that tenant’s other servers globally.
* Every tenant’s customer VRF is connected to the common shared services network to provide private reachability for those servers to use DNS, shared storage, monitoring, patching, and more.
* The customer VRF is a connectivity service that provides isolation among tenants. Any additional controls that are needed within a tenancy must be provisioned separately by using a gateway, security groups, or host-based controls.







 Routing consideration with VPC 

When routing on-premises subnets from the direct link through a VPC, you must create a route in the VPC routing table.
r010-e3a34cbb-d5e8-4713-a57e-3e35a7458272 inbound ipv4 all freeload-flavored-surging-repaying
r010-036c3a13-1c16-4425-9667-a4ec34b1702b inbound ipv4 icmp Type=8 0.0.0.0/0
r010-15591636-6976-493f-a94f-70721702860a inbound ipv4 tcp Ports:Min=22,Max=22 0.0.0.0/0
2. Delete the default rule that allows all outbound traffic.

ibmcloud is security-group-rule-delete $sg <rule_ID>







Keep in mind that in addition to any rules you create, you must also create the required [inbound and outbound rules](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-groupvpc-sg-inbound-outbound).







 Adding VPC security groups to clusters and worker pools during create time 

When you create a new VPC cluster, the default VPC security group, which has a randomly generated name, and the cluster security group, named kube-<cluster-id>, are automatically created and applied to all workers in the cluster. When you create your VPC cluster, you can also attach additional security groups alongside, or instead of, the default VPC security groups. The security groups applied to the workers in the cluster are a combination of the security groups applied when you create the cluster and [when you create the worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-groupvpc-sg-worker-pool). A total of five security groups can be applied to workers, including the default security groups and any security groups applied to the worker pool. Note that these security group options are only available in the CLI.

The security groups applied to a cluster cannot be changed once the cluster is created.
About IBM Cloud Gateway Appliance 

IBM Cloud® Gateway Appliances allow you to selectively route private and public network traffic through a full-featured enterprise level firewall powered by the software features of VyOS, JunOS or any other operating system (BYOA) you choose, such as full routing stacks, QoS and traffic sharing, policy-based routing, and VPN.

The appliances provide performance, ease of configuration, and maintenance advantages with the simplicity of running on a bare metal server. The hardware is sized to handle the routing/security load for multiple VLANs and can be ordered with redundant network links and redundant RAID arrays. All appliance features are customer-managed.

Both Juniper vSRX Standard and Virtual Router Appliance (VRA) are offered in two different modes: standalone or High Availability (HA) cluster.



 Firewall 

IBM Cloud Gateway Appliances deploy to protect your environment from external and internal threats by filtering both private and public facing traffic. Customers can manage the appliances themselves by defining policies and rules to allow or deny (among other actions) inbound or outbound network traffic, protecting their applications from internal and external users. Both IPv4 and IPv6 stacks are supported in a stateful manner.





 Virtual Private Network (VPN) gateway 

Connect your on-site data center or office to the IBM Cloud using VPN tunneling by provisioning your vSRX or VRA as a network gateway device. You can use an IPsec site-to-site VPN tunnel for secure communication from your enterprise data center or office to your IBM Cloud network. Remote access IPsec VPN is also supported.





 Network Address Translation (NAT) 

With IBM Cloud Gateway Appliances, you can provision application and database servers without public network interfaces while still allowing your servers to access the internet using source NAT. You can also hide your servers behind the gateway device with destination NAT for enhanced security.





 Enterprise-grade routing 

For multi-tiered applications on different isolated networks, the appliances enable you to build connectivity between these networks with greater flexibility. You can set up dynamic routing using Border Gateway Protocol (BGP), which allows you to announce your own public IP space to the IBM Cloud routers.
IBM-managed keys are generated and securely stored in a Block Storage for VPC vault that is backed by Consul and maintained by IBM Cloud® operations.

For more security, you can protect your data by using your own customer root keys (CRKs). You import your root keys to, or create them in, a supported key management service (KMS). Your root keys are safely managed by the supported KMS, either Key Protect (FIPS 140-2 Level 3 compliance) or Hyper Protect Crypto Services. Both KMS solutions offer the highest level of security (FIPS 140-2 Level 4 compliance). Your key material is protected in transit and at rest.

For more information, see [Supported key management services for customer-managed encryption](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-aboutkms-for-byok). To learn how to configure customer-managed encryption, see [Creating Block Storage for VPC volumes with customer-managed encryption](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-vpc-encryption).

You control access to your root keys stored in KMS instances within IBM Cloud® by using IBM Cloud Identity and Access Management (IAM). You grant access to the IBM Block Storage for VPC Service to use your keys. With the API, you can link a primary account that holds a root key to a secondary account, then use that key to encrypt new volumes in the secondary account. For more information, see [Cross-account encryption for multitenant storage resources](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started).

You can also revoke access at any time, for example, if you suspect your keys might be compromised. You can also disable or delete a root key, or temporarily revoke access to the key's associated data on the cloud. For more information, see [Managing root keys](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-managingbyok-manage-root-keys).
For a full list of command options, see [ibmcloud is instance-update](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-referenceinstance-update).





 Rename a virtual server instance using the API 

You can rename the virtual server instance in your IBM Cloud VPC by using the API.

The following example renames a virtual server instance from name to my-instance.

curl -X PATCH "$vpc_api_endpoint/v1/instances/$instance_id?version=2021-06-29&generation=2" -H "Authorization: $iam_token" -d '{"name": "my-instance"}'





 Stop and start a virtual server instance using the UI 

The stop action shuts down the guest operating system and then the virtual server instance is deprovisioned. This change frees the instance resources that were being consumed. The virtual server instance is transitioned to the Stop state. If the instance is stopped, the instance remains in the stopped state and must be started manually. Billing is [suspended](https://cloud.ibm.com/docs/vpc?topic=vpc-suspend-billing) for some compute resources while the instance is stopped. You cannot interact with an instance if it is stopped, but volumes remain provisioned. If the instance is started, normal interaction and billing continues.

A Force stop action triggers a power cycle reset of the virtual server instance.

The start action starts a virtual server instance that is in a stopped state.

From the Virtual server instances page in IBM Cloud console, click Stop or Start.

For z/OS virtual server instances only: You must shut down all the subsystems in the z/OS system to halt the virtual server instance. For more information, see [Shutting down z/OS virtual server instances](https://www.ibm.com/docs/en/wazi-aas/1.0.0?topic=vpc-shutting-down-zos-virtual-server-instances).





 Stop a virtual server instance using the CLI
Ordering IBM Cloud Direct Link Dedicated 

To order Direct Link Dedicated, you must determine the location connecting to IBM Cloud, complete the required Direct Link configuration information, then click Create to submit your order.



 Planning considerations 

Make sure that you review the following information before ordering Direct Link Dedicated:



* Before you begin, contact your service provider to determine the location to IBM Cloud by verifying your colocation or service provider's capabilities to reach the Meet Me Room and cross-connect into IBM Cloud.
* All subnets of the VPC or classic network will be connected to the direct link. When creating VPCs, make sure to create the VPCs with non-overlapping prefixes and unique subnets.



* To avoid IP address conflicts for classic connections to a direct link, don't use IP address 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 on-prem networks. On-prem routes that overlap are dropped.
* 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 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.
* To create inbound traffic rules, use the [ibmcloud is security-group-rule-add <sg> inbound command](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-referencesecurity-group-rule-add).

ibmcloud is security-group-rule-add $sg inbound <protocol> [--remote <remote_address> | <CIDR_block> | <security_group_ID>] [--icmp-type <icmp_type> --icmp-code <icmp_code>]] [--port-min <port_min>] [--port-max <port_max>]
* To create outbound traffic rules, use the [ibmcloud is security-group-rule-add <sg> outbound command](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-referencesecurity-group-rule-add).

ibmcloud is security-group-rule-add $sg outbound <protocol> [--remote <remote_address> | <CIDR_block> | <security_group_ID>] [--icmp-type <icmp_type> --icmp-code <icmp_code>]] [--port-min <port_min>] [--port-max <port_max>]



1. After you create custom outbound rules, get the ID of the default rule that allows all outbound traffic.

ibmcloud is sg $sg

Example output

Rules
ID Direction IP version Protocol Remote
r010-e3a34cbb-d5e8-4713-a57e-3e35a7458272 inbound ipv4 all freeload-flavored-surging-repaying
r010-036c3a13-1c16-4425-9667-a4ec34b1702b inbound ipv4 icmp Type=8 0.0.0.0/0
IBMCLOUD_CR_VPC_URL=url_value 

The custom server URL to use when obtaining an instance identity token and IAM token as a VPC VSI compute resource. This value replaces the default server endpoint of the VPC VSI instance identity token service.





 IBMCLOUD_TRACE=true 

Prints API request diagnostics to stdout. Use this variable to investigate how CLI commands are run. This variable prints many useful details to the standard output (your terminal). Use it to investigate how the CLI commands interact with the IBM Cloud platform and service APIs.





 IBMCLOUD_TRACE=path/to/trace.log 

Appends API request diagnostics to a log file. This variable prints many useful details to the specified log file.





 IBMCLOUD_HOME=path/to/dir 

Specifies the path to the configuration directory. The ibmcloud command reads and writes its session metadata to and from the specified path. Use the variable to work with multiple accounts or multiple sessions at the same time.

For more information about this environment variable, see [Working with multiple sessions with the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud-home).
A set of shared microservices is accessed through host names registered in the IBM Cloud® DNS Services. Each VPC is managed by a separate team isolated by IBM Cloud® Identity and Access Management. Optionally a IBM Cloud® Load Balancer can be used to scale out the shared microservice.

Virtual Private Cloud (VPC) Managing your account, resources, and access

+2

Transit Gateway,DNS Services



* 2 hours
* 2023-05-18



[Creating a resilient three-tier highly available infrastructure VPC in multiple regions with Terraform](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-create-three-tier-resilient-vpc-mzr)Creating a resilient three-tier highly available infrastructure VPC in multiple regions with Terraform

Terraform on IBM Cloud® enables predictable and consistent provisioning of IBM Cloud VPC infrastructure resources so that you can rapidly build complex, cloud environments. The IBM Cloud VPC infrastructure that is created uses Intel Xeon CPUs and additional Intel technologies. For more information about Terraform on IBM Cloud, see Terraform on IBM Cloud getting started tutorial.

Virtual Servers for Classic Virtual Private Cloud (VPC)

+2

IBM Cloud Load Balancer,Building infrastructure



* 30 minutes
* 2021-11-18



[Creating a resilient three-tier highly available infrastructure VPC with Autoscale by using Terraform](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-create-three-tier-resilient-vpc-autoscale)Creating a resilient three-tier highly available infrastructure VPC with Autoscale by using Terraform

Terraform on IBM Cloud® enables predictable and consistent provisioning of IBM Cloud VPC infrastructure resources so that you can rapidly build complex, cloud environments. The IBM Cloud VPC infrastructure that is created uses Intel Xeon CPUs and additional Intel technologies. For more information about Terraform on IBM Cloud, see Terraform on IBM Cloud getting started tutorial.

Virtual Servers for Classic Virtual Private Cloud (VPC)

+2

IBM Cloud Load Balancer,Building infrastructure



* 30 minutes
This service offers two types of VPNs, such as Site-to-site gateways that connect your on-premises network to the IBM Cloud VPC network and Client-to-site servers that allows clients to connect to VPN servers on internet.



See the following sections for more detailed overview for these offerings for on-premises connectivity, and architectural considerations when used with VMware workloads on VPC.





 Interconnecting VMware workloads with VPCs and IBM Cloud services 

Interconnecting workloads with VPCs and IBM Cloud services provides the capability to know how to interconnect VMware workloads that are running on a VPC with other workloads on other VPCs and IBM Cloud services.

The solution consists of the following key offerings:



* IBM Cloud Transit Gateway provisions and defines connections between resources on the IBM Cloud network, providing private interconnectivity between IBM Cloud data centers worldwide. You can connect IBM Cloud VPC, IBM Cloud classic infrastructure, and networks advertised over GRE tunnels on IBM Cloud classic infrastructure. You can also attach IBM Cloud Direct Link to your IBM Cloud Transit Gateway.
* With Virtual Private Endpoint (VPE) for VPC, you can connect to supported IBM Cloud services from your VPC network. To connect, you must use the IP addresses that you choose and that are allocated from a subnet within your VPC. You can use VPEs with your VMware workloads that run on VPC.



When you use the services that were mentioned previously, the data remains within the private IBM Cloud backbone and is optimized for performance.





 Related links 



* [IBM Cloud VPC getting started](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started)
* [IBM Cloud VPC Bare Metal Servers](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-for-bare-metal-servers)
* [IBM Cloud VPC RYO VMware reference architecture](https://cloud.ibm.com/docs/vmwaresolutions?topic=vpc-ryo-overview)
* [Virtual private endpoints](https://cloud.ibm.com/docs/vpc?topic=vpc-about-vpe)
* Appliances and virtual appliances



* IP range selection: Provision subnets of any size, as small as /29 and up to /9 from any IP address space.
* [Network ACLs](https://cloud.ibm.com/docs/vpc?topic=vpc-using-acls): Access control lists (ACLs) can be used to control all incoming and outgoing traffic in IBM Cloud VPC.
* [Public gateways](https://cloud.ibm.com/docs/vpc?topic=vpc-public-gateways): Attaching a public gateway allows all attached resources to communicate with the public internet.
* [Routing tables](https://cloud.ibm.com/docs/vpc?topic=vpc-about-custom-routes): IBM Cloud VPC automatically generates a default routing table for the VPC to manage traffic in the zone. By default, this routing table is empty. You can add routes to the default routing table, or create a custom routing table, and then add routes to the new table.
In a distributed vSwitch topology and when vMotion is used for a VM, ensure that the VLAN ID of this port group is included in the VLAN allowlist of all the IBM Cloud bare metal server part of the cluster.





 VPC access control lists (ACLs) and security groups (SGs) with VMware VMs on VPC subnets 

Bare metal server for VPC provides full support for VPC networking features. Network security capabilities, such as security groups and Access Control Lists (ACL) can be used with bare metal server PCI and VLAN interfaces. In this design, both the VMware infrastructure subnets, which are used to carry VMware System Traffic Types, and VPC subnets for workloads VMs share the same routing domain. Best practices advice you to create required network security measures for this process.



 Access control list with VMware workloads 

An Access Control List can manage by allowing or denying inbound and outbound traffic for a subnet. An ACL is stateless, which means that inbound and outbound rules must be specified separately and explicitly. Each ACL consists of rules based on a source IP, source port, destination IP, destination port, and protocol. Every VPC has a default ACL that allows all inbound and outbound traffic. You can edit the default ACL rules, or create a custom ACL.

As ACLs are applied to a subnet. You can use them as with Virtual Servers to control traffic to and from the VPC subnets. Also, you can create isolated subnets, for example, for vSAN™, vMotion and TEP traffic.

For more information about ACLs, see [Security in VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-security-in-your-vpc). For more information about ACLs with IBM Cloud bare metal server, see [Introduction to IBM Cloud bare metal server networking](https://cloud.ibm.com/docs/vpc?topic=vpc-bare-metal-servers-network).





 Security groups with VMware workloads
ibm-is-ng Create a Virtual Private Cloud (VPC) for Generation 2 compute, configure a VPC load balancer with custom routing rules. Then, add a virtual server instance to your VPC that you can access from the internet by using a public IP address. Then, create another VPC Gen 2 and configure it with a VPN gateway with custom IPsec and IKE networking rules. You also learn how to create VPC Gen 2 block storage volumes. <br> <br>Resources <br><br><br><br> * ibm_is_vpc<br> * ibm_is_vpc_route<br> * ibm_is_subnet<br> * ibm_is_lb<br> * ibm_is_lb_listener<br> * ibm_is_lb_listener_policy<br> * ibm_is_lb_listener_policy_rule<br> * ibm_is_vpn_gateway<br> * ibm_is_vpn_gateway_connection<br> * ibm_is_ssh_key<br> * ibm_is_instance<br> * ibm_is_floating_ip<br> * ibm_is_security_group_rule<br> * ibm_is_ipsec_policy<br> * ibm_is_ike_policy<br> * ibm_is_volume<br> * ibm_is_public_gateway<br><br><br> [View code snippet](https://github.com/IBM-Cloud/terraform-provider-ibm/tree/master/examples/ibm-is-ng)