vania-janet/multiturn-rag-retrieval-data huggingface dataset:
VPC load balancer Basic load balancing that exposes the app with a private hostname Quickly expose one app to a private network with a VPC load balancer-assigned private hostname. [Create a private LoadBalancer service](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaas) in your cluster. A multizonal VPC load balancer is automatically created in your VPC that assigns a hostname to your LoadBalancer service for your app. 
 Ingress HTTP(S) load balancing that exposes the app with a subdomain and uses custom routing rules Implement custom routing rules and SSL termination for multiple apps. [Create an Ingress resource for the default private Ingress controller in clusters with a private cloud service endpoint only](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-private-exposepriv-se-priv-controller), or [create an Ingress resource for a custom private Ingress controller in clusters with a public cloud service endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-private-expose).
Creating a VPC](https://cloud.ibm.com/docs-content/v1/content/f89cc64b006ca59b35404693959c83d5747fee3e/sap//images/quickstudy-intel-vs-gen2-image6.png)

Figure 2. Creating a VPC



1. Enter a unique Name for the VPC, for example, sap-test-inst.
2. Keep the default Resource group. Use resource groups to organize your account resources for access control and billing purposes. For more information, see [Best practices for organizing resources in a resource group](https://cloud.ibm.com/docs/account?topic=account-account_setup). For this example, you can use the default value.
3. Optional: Tags. Enter tags to help you organize and find your resources. You can add more tags later. For more information, see [Working with tags](https://cloud.ibm.com/docs/account?topic=account-tag).
4. Keep the Default security group settings, which allow inbound SSH and ping traffic to virtual server instances in this VPC.
5. Optional: Classic access. Select whether you want to enable your VPC to access classic infrastructure resources. For more information, see [Setting up access to classic infrastructure](https://cloud.ibm.com/docs/vpc?topic=vpc-setting-up-access-to-classic-infrastructure).

You can enable a VPC for classic access only while you are creating it. In addition, you can have only one classic access VPC in your account at any time.
6. Optional: Default address prefixes. Disable this option if you don't want to assign default subnet address prefixes to each zone in your VPC. After you create your VPC, you can go to its details page and set your own subnet address prefixes.
Before you can use the API to create your VPC, you must get an IAM token, store the endpoint as a variable, and verify that you have access to the VPC API service.

The following examples use the us-south regional endpoint. To view additional API endpoints, see [Virtual Private Cloud API](https://cloud.ibm.com/apidocs/vpcapi-endpoint).



 Step 1: Store your API key as a variable 

Run the following command to store the API key for your account in an environment variable. If you don't have an API key, see [Creating an API key](https://cloud.ibm.com/docs/account?topic=account-userapikeycreate_user_key).

apikey="<YOUR_API_KEY>"





 Step 2: Get an IBM Identity and Access Management (IAM) token 

Run the following command to get and parse an IAM token by using the JSON processing utility [jq](https://stedolan.github.io/jq/). You can modify the command to use another parsing tool, or you can remove the last part of the command if you prefer to manually parse the token.

iam_token=curl -k -X POST 
--header "Content-Type: application/x-www-form-urlencoded" 
--header "Accept: application/json" 
--data-urlencode "grant_type=urn:ibm:params:oauth:grant-type:apikey" 
--data-urlencode "apikey=$apikey" 
"https://iam.cloud.ibm.com/identity/token" |jq -r '(.token_type + " " + .access_token)'

To view the IAM token, run echo $iam_token. The result should look like this:

Bearer <your token>

The Authorization header expects the token to begin with "Bearer". If the result doesn't include "Bearer", update the iam_token variable to include it.
[VPC design for VMware deployment](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/vpc-ryo-diagrams-vpc-physical.svg)

Figure 1. VPC network design for VMware deployment

For this architecture, a new VPC is created for VMware workloads for simplicity. To connect to other workloads, you can use IBM Cloud® interconnectivity solutions. If needed, you might customize and create your own design, and also integrate the IBM Cloud bare metal servers with your existing VPCs.

The following table lists the recommended subnets in VPC. It is based on the recommendation to separate System Traffic Types logically and a dedicated VPC subnet for each user used. As each VMK host needs its own IP, it is recommended to keep the PCI interfaces (management) hosts on their own subnet. Also, place other management instances (such as vCenter®, NSX-T managers, NSX-Edge management interfaces) on their own subnet. It allows easier segmentation, sizing, and provides better scalability.



Table 1. VPC subnets for System Traffic Types

 Subnet name System traffic type Subnet sizing guidance 

 vpc-mgmt-subnet Management appliance traffic Number of Management Appliances 
 vpc-host-subnet Host management traffic Number of Hosts 
 vpc-vmot-subnet vMotion traffic Number of Hosts 
 vpc-vsan-subnet vSAN traffic Number of Hosts 
 vpc-tep-subnet TEP traffic Number of Hosts + <br>2 x Edge Nodes 



To be able to create subnets in VPC, you must create a VPC prefix. VPC prefixes are defined per zone. To simplify routing, it is recommended to allocate the recommended subnets from a single prefix. Which means that to be able to accommodate 5 subnets, you need one /21 prefix to cater addresses for about 120 hosts per zone.
"resourceGroupId": "crn:v1:bluemix:public:resource-controller::a/67db3d7ff3f34220b40e2d81480754c9::resource-group:d272ce832535498e9142b557ff8638ed"
},
"reason": {
"reasonCode": 403,
"reasonType": "Forbidden",
"reasonForFailure": "Your access token is invalid or does not have the necessary permissions to perform this task"
},
"requestData": {
"generation": "2",
"requestId": "b266a31c-b359-4ecb-8b81-a27c1b2cdb7b"
},
"responseData": {
"responseURI": "/v1/vpcs/"
}
}
Show more

You can also search events by using a resource identifier. A resource ID is a UUID and is the last identifier in a CRN. For example:

crn:v1:bluemix:public:is:au-syd:a/67db3d7ff3f34220b40e2d81480754c9::vpc:<resourceID>

Requests for provisioning resources do not contain a resource ID.

If you do not find a context-based restriction event in Activity Tracker, it's possible access was denied due to IAM access policies. For more information, see [VPC IAM getting started guide](https://cloud.ibm.com/docs/vpc?topic=vpc-iam-getting-started).





 Client-to-site VPN data plane impact with context-based restrictions
IBM Log Analysis Collects logs that are generated by the VPC service. Depending on the type of log, it might be consumed by IBM support and operations, customers, or both 
 IBM Cloud Activity Tracker Forwards service audit events to the IBM Cloud® Activity Tracker instance that is set up in the region by the cloud account owner. For more information, see [Activity Tracker events](https://cloud.ibm.com/docs/vpc?topic=vpc-at-events). 
 Technical Integration Point (Tivoli Integrated Portal) Notifies IBM's support and operations team of VPC service outages and incidents. 
 Operational Support Systems Event Data Broker (OSS EDB) Monitors the health of the internal components of the VPC service. 
 Ops Dashboard Allows IBM's operations team to track the inventory and consumption of VPC resources. 
 IBM Cloud Databases for Elasticsearch Houses tracing data that is used for debugging, troubleshooting, and performance monitoring of the internal components of the VPC service. 
 IBM Cloud Monitoring Sends metrics to IBM Cloud® Monitoring. These metrics are used to debug, troubleshoot, and monitor performance of the VPC service. You can also use IBM Cloud Monitoring to monitor the health and performance of your virtual private cloud. For more information, see [Monitoring metrics](https://cloud.ibm.com/docs/vpc?topic=virtual-servers-sysdig-monitoring-metrics). 
 IBM Cloud Secrets Manager Stores and manages certificates that are used to securely deploy VPC components, and to secure communication between VPC components. 
 Digicert Issuer of cloud.ibm.com SSL certificates. 
 DNS Services Maps IBM Cloud services FQDN to IP addresses that provides access to those services within the customer's VPC. 
 Pulsar Notifies of encryption key changes at IBM Key Protect or Hyper Protect Crypto Services that affect volumes, instances, or images in VPC. 
 New Relic Stores a set of metrics events that are used by IBM's internal infrastructure team. 
 LaunchDarkly Manages the rollout of new features in VPC Infrastructure Services. LaunchDarkly provides feature flags used to control visibility and availability of a feature to a selected user base.
For more information, see [Required permissions for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-resource-authorizations-required-for-api-and-cli-calls).



For more information about assigning user roles in the UI, see [Managing user permissions for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-user-permissions-for-vpc-resources).

You can also assign user roles by using IBM Cloud® Command Line Interface (CLI). You can select resources by using resource attributes. For more information, see [VPC resource attributes](https://cloud.ibm.com/docs/vpc?topic=vpc-resource-attributes).







 Resource groups 

A resource group is a collection of resources, such as an entire VPC or a single subnet that are associated for establishing authorization and usage. You can think of a resource group as a collection of infrastructure resources that might be used by a project, a department, or a team.

Large enterprises might divide a VPC into various resource groups, whereas smaller companies might need only one resource group because all team members have access to the entire VPC. If you are familiar with OpenStack, a resource group is similar in concept to a Project in OpenStack Keystone.

Assignment of a resource to a resource group can be done only when the resource is created. Resources can't change resource groups after they are created.

If you want to use multiple resource groups, it’s good to plan for how you want to assign the resources and the users in your organization to each resource group.

For more information about resources group, see [Resource groups](https://cloud.ibm.com/docs/account?topic=account-rgs).





 Access management tags 

[Access management tags](https://cloud.ibm.com/docs/account?topic=account-access-tags-tutorial) are metadata that is added to resources to help organize access control relationships. Tags create flexible resource groupings for you to administer.
* Check whether Application Load Balancer for VPC is configured with multiple members in the pool
* Check whether an OpenShift cluster has worker nodes across multiple zones
* Check whether Cloud Object Storage bucket resiliency is set to cross region
* Check that any Cloud Object Storage buckets used by Activity Tracker Event Routing are configured as cross-region
* Check that Hyper Protect Crypto Services has failover units in at least 2 different regions that are Financial Services Validated
* Check whether Application Load Balancer for VPC has health check configured when created
* Check whether Application Load Balancer for VPC listener is configured with default pool
* Check whether each Virtual Private Cloud is configured to use at least # zones







 NIST supplemental guidance 

Recovery is executing information system contingency plan activities to restore organizational missions/business functions. Reconstitution takes place following recovery and includes activities for returning organizational information systems to fully operational states. Recovery and reconstitution operations reflect mission and business priorities, recovery point/time and reconstitution objectives, and established organizational metrics consistent with contingency plan requirements. Reconstitution includes the deactivation of any interim information system capabilities that may have been needed during recovery operations. Reconstitution also includes assessments of fully restored information system capabilities, reestablishment of continuous monitoring activities, potential information system reauthorizations, and activities to prepare the systems against future disruptions, compromises, or failures. Recovery/reconstitution capabilities employed by organizations can include both automated mechanisms and manual procedures.
value = "ssh root@ibm_is_floating_ip.fip1.address"
}

output vpc_id {
value = ibm_is_vpc.vpc.id
}

In this example, two output values are defined, the sshcommand to access the virtual server instance in your VPC and the vpc_id.
2. Retrieve the ID of the VPC workspace that you created.

Through console:



* From the [workspace dashboard ![External link icon](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/icons/launch-glyph.svg)](https://cloud.ibm.com/schematics/workspaces), select the VPC workspace.
* Select the Settings tab.
* Find the workspace ID in the Summary section.



Through CLI:



* List available workspaces in your account.

ibmcloud schematics workspace list
* Find the workspace ID in the ID column of your command-line output.



The Schematics ibmcloud terraform command usage displays warning and deprecation message as Alias 'terraform' will be deprecated. Use 'schematics' or 'sch' in your commands.
3. Create another Terraform configuration file that is named remotestate.tf to access the output parameters of the vpc.tf file by using the ibm_schematics_output data source. To allow version control of this file, make sure to store this configuration file in a GitHub or GitLab repository.

data "ibm_schematics_workspace" "vpc" {
workspace_id = "<schematics_workspace_ID>"
}

data "ibm_schematics_output" "vpc" {
workspace_id = "<schematics_workspace_ID>"
The VPC load balancer that is automatically created in your VPC outside of your cluster when you use one of these services routes traffic to your app. You can improve the security of your cluster and control public network traffic to your apps by replacing the kube-<vpc-id> security group, which is automatically applied to the VPC ALB, with a security group that you create and manage. When applied to ALBs, security groups control which inbound traffic is permitted to your cluster through the ALB.

Ready to get started with a cluster for this scenario? After you plan your [high availability](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clusters) and [worker node](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodes) setups, see [Creating VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters).







 Extend your on-premises data center to a VPC cluster 

In this scenario, you run workloads in a VPC cluster. However, you want these workloads to be accessible only to services, databases, or other resources in your private networks in an on-premises data center. Your cluster workloads might need to access a few other IBM Cloud services that support communication over the private network.

Zoom

![Network setup for a VPC cluster that extends an on-prem data center.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/roks_ov_vpc_priv.png)

Figure 1.Network setup for a VPC cluster that extends an on-prem data center



 Worker-to-worker communication 

To achieve this setup, you create VPC subnets in each zone where you want to deploy worker nodes. To run default Red Hat OpenShift components such as the web console or OperatorHub, public gateways are required for these subnets.
If you require the VPC to have access to your classic resources, see [Setting up access to classic infrastructure](https://cloud.ibm.com/docs/vpc?topic=vpc-setting-up-access-to-classic-infrastructure). You can only enable a VPC for classic access while creating it. In addition, you can only have one classic access VPC in your account at any time.





 Create a private catalog 

This step is optional. If you plan share images from a private catalog, the private catalog must be created first. If you select a catalog image that belongs to a different account, there are additional considerations and limitations to review. See [Using cross-account image references in a private catalog in the UI](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images&interface=uiprivate-catalog-image-reference-vpc-ui). To create a private catalog, see the tutorial [Onboarding software to your catalog by using the CLI](https://cloud.ibm.com/docs/account?topic=account-create-private-catalog&interface=clicreate-cicd-product).





 Create a subnet 

Before you create a subnet, select the zone and address prefix in which to create it. To list the address prefixes for each zone in your VPC, run the following command:

ibmcloud is vpc-address-prefixes $vpc

Let's pick the default address prefix for the us-south-3 zone. From the command output, note the CIDR block of the address prefix. When you create a subnet, you must specify an IP range that's within one of the address prefixes of the selected zone.

A subnet cannot be resized after it is created.

ibmcloud is subnet-create my-subnet $vpc us-south-3 --ipv4-cidr-block "10.0.1.0/24"

From the output that's returned, save the ID in a variable so you can use it later, for example:
To get started protecting your DNS Services resources with context-based restrictions, see the tutorial for [Leveraging context-based restrictions to secure your resources](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-tutorial).



 Creating network zones 

A network zone represents an allowlist of IP addresses where an access request is created. It defines a set of one or more network locations that are specified by the following attributes:



* IP addresses, which include individual addresses, ranges, or subnets
* VPCs





 Creating network zones by using the API 

You can create network zones by using the create-zone command. For more information, see the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-zone).

The addresses attribute specifies individual IP addresses, ranges, subnets, and VPCs where requests originating from are permitted.

{
"name": "example-zone",
"description": "this is an example of zone",
"account_id": "12ab34cd56ef78ab90cd12ef34ab56cd",
"addresses": [
{
"type": "ipAddress",
"value": "169.23.56.234"
},
{
"type": "ipRange",
"value": "169.23.22.0-169.23.22.255"
},
{
"type": "subnet",
"value": "192.0.2.0/24"
},
{
"type": "vpc",
"value": "crn:v1:bluemix:public:is:us-south:a/12ab34cd56ef78ab90cd12ef34ab56cd::vpc:r134-d98a1702-b39a-449a-86d4-ef8dbacf281e"
}
]
}

{
Managing IPSec VPN tunnels (ibmcloud sl ipsec) 

IBM Cloud® VPN access allows users to manage all servers remotely and securely over the IBM Cloud private network. A VPN connection from your location to the private network gives you the capability for out-of-band management and server rescue through an encrypted VPN tunnel.

Use the following commands from the IBM Cloud Command Line Interface to manage IPSec VPN tunnels in the IBM Cloud classic infrastructure IPSec VPN service.



 ibmcloud sl ipsec cancel 

Cancel an IPSec VPN tunnel context:

ibmcloud sl ipsec cancel CONTEXT_ID [OPTIONS]

Command options:

--immediate
: Cancel the IPSec immediately instead of on the billing anniversary.

--reason
: An optional reason for cancellation.

-f, --force
: Force operation without confirmation.





 ibmcloud sl ipsec config 

Request configuration of a tunnel context:

ibmcloud sl ipsec config CONTEXT_ID [OPTIONS]





 ibmcloud sl ipsec detail 

List IPSec VPN tunnel context details:

ibmcloud sl ipsec detail CONTEXT_ID [OPTIONS]

Command options:

-i, --include
: Include extra resources. Options are: at,is,rs,sr,ss.





 ibmcloud sl ipsec list 

List IPSec VPN tunnel contexts:

ibmcloud sl ipsec list [OPTIONS]

Command options:

--order
: Filter by ID of the order that purchased the IPSec.





 ibmcloud sl ipsec order 

Order an IPSec VPN tunnel:

ibmcloud sl ipsec order [OPTIONS]

Command options:

-d, --datacenter
: Required. Short name of the datacenter for the IPSec. For example, dal09.





 ibmcloud sl ipsec subnet-add 

Add a subnet to an IPSec tunnel context:

ibmcloud sl ipsec subnet-add CONTEXT_ID [OPTIONS]

Command options:
VPC subnets provide IP addresses for your worker nodes and load balancer services in the cluster, so [create a VPC subnet with enough IP addresses](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnetsvpc_basics_subnets), such as 256. You can't change the number of IPs that a VPC subnet has later.

ibmcloud is subnet-create <subnet_name> <vpc_id> --zone <vpc_zone> --ipv4-address-count <number_of_ip_address> --ipv4-cidr-block <prefix_range>
5. To run default Red Hat OpenShift components such as the web console or OperatorHub, and to allow your cluster to access public endpoints such as a public URL of another app or an IBM Cloud service that supports public cloud service endpoints only, you must attach a public gateway to your subnet.



1. Create a public gateway in each zone. Consider naming the public gateway in the format <cluster>-<zone>-gateway. In the output, note the public gateway's ID.

ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>

Example output

ID 26466378-6065-4716-a90b-ac7ed7917c63
Name mycluster-us-south-1-gateway
Floating IP 169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63)
Status pending
Created 2019-09-20T16:27:32-05:00
Zone us-south-1
VPC myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
Resource group -
2. By using the IDs of the public gateway and the subnet, attach the public gateway to the subnet.
If you require the VPC to have access to your classic resources, see [Setting up access to classic infrastructure](https://cloud.ibm.com/docs/vpc?topic=vpc-setting-up-access-to-classic-infrastructure). You can only enable a VPC for classic access while creating it. In addition, you can only have one classic access VPC in your account at any time.





 Create a private catalog 

This step is optional. If you plan share images from a private catalog, the private catalog must be created first. If you select a catalog image that belongs to a different account, there are additional considerations and limitations to review. See [Using cross-account image references in a private catalog in the UI](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images&interface=uiprivate-catalog-image-reference-vpc-ui). To create a private catalog, see the tutorial [Onboarding software to your catalog by using the CLI](https://cloud.ibm.com/docs/account?topic=account-create-private-catalog&interface=clicreate-cicd-product).





 Create a subnet 

Before you create a subnet, select the zone and address prefix in which to create it. To list the address prefixes for each zone in your VPC, run the following command:

curl -X GET "$vpc_api_endpoint/v1/vpcs/$vpc/address_prefixes?version=$api_version&generation=2" -H "Authorization:$iam_token"

Let's pick the default address prefix for the us-south-3 zone. From the response, note the CIDR block of the address prefix. When you create a subnet, you must specify an IP range that's within one of the address prefixes of the selected zone.

A subnet cannot be resized after it is created.

curl -X POST "$vpc_api_endpoint/v1/subnets?version=$api_version&generation=2" -H "Authorization:$iam_token" -d '{