vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Connectivity options within the IBM Cloud VPC Infrastructure network 



* Floating IP, a public internet IPv4 address, which can be configured with Security Groups to allow only certain network connection access on defined protocols and ports from specified source/target addresses. For initial tests option is often used, with more detail in the short guide on [Connecting to your Linux Virtual Server instance](https://cloud.ibm.com/docs/vpc?topic=vpc-vsi_is_connecting_linux).
* VPC IPSecVPN, service from the IBM Cloud catalog and deploys a VPN Gateway to a VPC and creating a VPN Connection with advanced configuration options available for the IPsec Tunnel; including integration with authentication strategies such as Microsoft Active Directory.
* IBM Cloud® Direct Link 2.0, the latest enhancement and the most robust connection available, now with access to both Classic Infrastructure network and VPC Infrastructure network simultaneously from your internal network to IBM Cloud's Availability Zones (Data centers) that use Network Service Providers, Point of Presence (PoP), or directly between the data center colocation Room (also called a Meet Me Room). This is available up to 10 Gbps network throughput as a Routed OSI Layer-2/3 connection, and is designed for enterprise workload connections.



* More information on [Direct Link 2.0](https://cloud.ibm.com/docs/dl). To find from a specified site location to IBM Cloud and which network service providers are available, use [Cloud Pathfinder for IBM Cloud](https://ibm.find.cloud) (powered by [Cloudscene](https://cloud.ibm.com/docs/cloudscene.com))







 VPC VPN Gateway 

To connect to a virtual server on VPC through a secure IPsec tunnel, a VPN Gateway is created for the VPC.
About client-to-site VPN servers 

Client VPN for VPC provides client-to-site connectivity, which allows remote devices to securely connect to the VPC network using an OpenVPN software client. This solution is useful for telecommuters who want to connect to the IBM Cloud from a remote location, such as a home office, while still maintaining secure connectivity.

Highlights include:



* TLS 1.2/1.3-based secure/encrypted connectivity over the internet
* Supports both stand-alone (pilot) and high availability (production) deployments
* Privately interconnect Classic IaaS and VPCs on IBM Public Cloud
* Availability in all [MZRs world wide](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-in-a-different-region)
* High availability spanning across zones, providing better performance and resiliency
* Provides added layers of security with integrated authentication methods





 Architecture 

Figure 1 illustrates an example VPN server setup to connect resources in and out of the VPC. The VPN server is provisioned on two subnets within a user's VPC. There are also two VPN server members that work in Active/Active High Availability (HA) mode. All of the VPN server members can communicate with target resources. There is one public IP address assigned to each of the members, and a DNS hostname record is created for the VPN server. The hostname is resolved to the VPN member's public IP address. VPN clients get two public IP addresses via DNS resolution and try two IP addresses randomly to connect with one of the VPN members. The VPN client attempts to reconnect and switch to an active VPN server member if one member is down.

A DNS service is deployed as part of the VPN service. The DNS name provided ends with appdomain.cloud.

Zoom

!
* To add or remove virtual connections to VPCs, or to accept or reject a connection request, the user must also have Editor or Administrator platform-access role permissions to the VPC. See [VPC: Getting started with IAM](https://cloud.ibm.com/docs/vpc?topic=vpc-iam-getting-started) for more information.

Notes:



* All Direct Link resources exist in a resource group. Creating a Direct Link resource requires Editor access to the selected resource group.
* For information about assigning user roles in the console, see [Managing access to resources](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources).





 Assigning access to Direct Link in the console 

There are two common ways to assign access in the console:



* Access policies per user. You can manage access policies per user from the Manage > Access (IAM) > Users page in the console. For information about the steps to assign IAM access, see [Managing access to resources](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources&interface=uiaccess-resources-console).
* Access groups. Access groups are used to streamline access management by assigning access to a group once, then you can add or remove users as needed from the group to control their access. You manage access groups and their access from the Manage > Access (IAM) > Access groups page in the console. For more information, see [Assigning access to a group in the console](https://cloud.ibm.com/docs/account?topic=account-groups&interface=uiaccess_ag).







 Authorization considerations for cross-account virtual connections 

The following table shows the authorization changes for cross-account virtual connections.

A cross-account virtual connection means that the gateway exists in an IBM Cloud account and a virtual connection in that gateway connects to a VPC in a different IBM Cloud account. This setup requires special authorization considerations because the objects (the directlink gateway and the VPC) and their resource groups do not exist in both accounts.



Table 2.
Instance metadata API error codes 

As covered in [Error handling](https://cloud.ibm.com/apidocs/vpc-metadataerror-handling), the VPC Instance Metadata API uses standard HTTP response codes to indicate the outcome of a request. For example, a 4xx-series response indicates a failure that the client must resolve. A 5xx-series response indicates a service failure.

Additionally, all 4xx and 5xx responses include a JSON error response object that provides additional information about the problem. This information includes a trace property whose value might be requested by IBM support when they troubleshoot the failure, and an errors array property that contains one or more specific errors that are related to the problem. Each item in the errors array uses the following JSON schema:



* code - Error code string, such as invalid_value
* message - Text string that describes the error message, for example, "The value provided for the expires_in field must be between 5 and 3600."
* more_info - If present, a link to the documentation about this error
* target - For errors that return a target property in the response, review the subproperties for clues:



* name of the problematic field, query parameter, or header
* type of input where the problem was found, such as a field
* value (if present) the problematic value within the field, query parameter, or header





Example 400 JSON error response object:

{
"errors": [
{
"code": "invalid_value",
"message": "The expires_in field must not exceed 3600.",
"more_info": "https://cloud.ibm.com/docs/vpc?topic=vpc-imd-configure-service",
"target": {
"name": "expires_in",
"type": "field",
"value": "7200"
}
}
],
"status_code": 400,
Choosing IP ranges for your VPC 

Use Classless Inter-Domain Routing (CIDR) notation in the format <IPv4_address>/number, such as 10.10.0.0/16. Reserve the last 16 bits (65,536 addresses) of the IPv4 as 0s so that you can use them for various subnet IP addresses within the same IBM Cloud® VPC, such as 10.10.1.0/24.

For a definition on CIDR notation, see [RFC 1518](https://tools.ietf.org/html/rfc1518) and [RFC 1519](https://tools.ietf.org/html/rfc1519).

If you use an IP range outside of the ranges [RFC 1918](https://tools.ietf.org/html/rfc1918) defines (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) for a subnet, the instances that are attached to that subnet might be unable to reach parts of the public internet. If you plan to configure VPCs that use both non-RFC-1918 addresses and also have public connectivity (floating IP addresses or public gateways), make sure to use a custom route that contains the Delegate-VPC action.

The smaller the number after the slash, the more IP addresses that you are allocating. The number after the slash represents the number of leading bits in the subnet's prefix mask.

Table 1 lists the number of available addresses in a subnet, based on its specified CIDR block size:



Table 1. Available addresses in a subnet

 CIDR block size  Available addresses 

 /22              1019                
 /23              507                 
 /24              251                 
 /25              123                 
 /26              59                  
 /27              27                  
 /28              11
* Select the Add/Modify Context Address Translations and Apply Configurations to save and apply the configuration.



This action sets up a static one-to-one network translation for the return traffic, which is used by your hosts behind the IBM Cloud VPN concentrator to communicate with the hosts behind the remote VPN peer. For example, all traffic for IP 10.1.255.92 will be translated and forwarded to the customer's IP 192.168.10.15. This forwarding eliminates the need for more route entries on the IBM Cloud server.

Due to security reasons, IBM does not provide specific hardware or software/operating system information about the equipment used to host our IPsec and SSL VPN services.





 Known restrictions 

Due to incompatibilities with our IBM CLoud IPsec VPN service, you are unable to build IPsec VPN tunnels with other major cloud providers, such as AWS, Azure, and Google Cloud. If you feel that building an IPsec VPN tunnel between your IBM Cloud environment and any of these providers is necessary, reach out to the IBM Sales team to discuss options that are available, such as a personal gateway appliance.
Network setup for a VPC cluster that runs internet-facing app workloads





 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. Then, you create a VPC cluster that uses these VPC subnets.





 Worker-to-master and user-to-master communication 

You can choose to allow worker-to-master and user-to-master communication over the public and private networks, or over the private network only.



* Public and private cloud service endpoints: Communication between worker nodes and master is established over the private network through the private cloud service endpoint. By default, all calls to the master that are initiated by authorized cluster users are routed through the public cloud service endpoint.
* Private service endpoint only: Communication to master from both worker nodes and cluster users is established over the private network through the private cloud service endpoint. Cluster users must either be in your VPC network or connect through a [VPC VPN connection](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-vpnaas).







 Worker communication to other services or networks 

If your app workload requires other IBM Cloud services, your worker nodes can automatically, securely communicate with IBM Cloud services that support private cloud service endpoints over the private VPC network.





 External communication to apps that run on worker nodes 

After you test your app, you can expose it to the internet by creating a public Kubernetes LoadBalancer service or using the default public Ingress application load balancers (ALBs). 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.
Working with pools 

The IBM Cloud® Network Load Balancer for VPC (NLB) pool is a group of back-end targets that receive the inbound customer traffic from the load balancer and provide your outbound traffic response. The pool has a protocol, a load-balancing algorithm, the back-end targets (VPC instances), the health checks for the back-end targets, and the session stickiness.

You can configure pools when [creating a network load balancer](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-ui-creating-network-load-balancer), or later with the following procedure:



1.  From your browser, open the [IBM Cloud console](https://cloud.ibm.com/login) and log in to your account.
2.  Select the Navigation Menu icon ![Navigation Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg), then click VPC Infrastructure > Load balancers.
3.  Click the network load balancer that you want to change.
4.  On the network load balancer details page, click the back-end pools tab and select the pool that you want to edit.
5.  Select the new options for your pool. You have the following options:



*  Pool Name: The name for your pool. Ideally, a name that describes the function that is performed by this pool.
*  Protocol: The network traffic protocol for your traffic.
*  Method: The load-balancing algorithm for the pool.
*  Session stickiness: Whether all requests during a user's session are sent to the same instance.
*  Health check: For more information about configuring health checks, see [Working with health checks](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-health-checksnlb-health-checks).
* Access groups will need to be defined so only certain users have the ability to create and manage the VPC network settings (i.e. CIDR ranges, Subnet ACLs rules, etc.).
* When you create your cluster, you must choose a VPC networking setup so that certain cluster components can communicate with each other and with networks or services outside of the cluster.



* Worker-to-worker communication: All worker nodes must be able to communicate with each other on the private network through VPC subnets.
* Worker-to-master and user-to-master communication: Your worker nodes and your authorized cluster users can communicate with the Kubernetes master securely over virtual private endpoints or cloud service endpoints.
* Worker communication to other services or networks: Allow your worker nodes to securely communicate with other IBM Cloud services, such as IBM Cloud® Container Registry, to on-premises networks, to other VPCs, or to classic infrastructure resources.
* External communication to apps that run on worker nodes: Allow public or private requests into the cluster as well as requests out of the cluster to a public endpoint.



* Understanding of [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-iks-overviewservice-concepts)
* Components that are set up in an IBM Cloud Kubernetes Service [VPC cluster architecture](https://cloud.ibm.com/docs/containers?topic=containers-service-archarchitecture_vpc)

![IKS on VPC](https://cloud.ibm.com/docs-content/v1/content/b7b9235ce6abd45b66931867c388cf107d38e15b/cloud-native-journey/kubernetes-on-vpc/images/overview/cs_org_ov_vpc.png)







 Next Steps 

The next step on the deployment journey is:



* [Prepare your IBM Cloud account](https://cloud.ibm.com/docs/cloud-native-journey?topic=cloud-native-journey-cloud-native-prepare-account)
In the [IBM Cloud](https://cloud.ibm.com/) console, click on the Manage menu and select [Context-based restrictions](https://cloud.ibm.com/context-based-restrictions). In the overview page, click on Create a network zone.
3. Enter VPCzone as name. Under Allowed VPCs, select the one with your Kubernetes Service cluster. Click Next to review, then Create the zone.
4. Next, create a rule using the zone by clicking on Rules in the navigation on the left, then Create.
5. Select Container Registry in the Service section and click Next.
6. Then, under Resources, choose Specific resources. Pick Resource Type as attribute and specify namespace as value. Add another condition and configure Resource Name as YOUR_INITIALS-e2esec (the same value as in step 1). Click Review, then Continue.
7. Select the VPCzone you created earlier from the list. Then use Add and Continue to get to the last step of the dialog. Mark the Enforcement as Report-only. Thereafter, Create the rule.



Be aware that CBR zones and rules are deployed asynchronously. It may take up to few minutes for them to become active (eventually consistent).





 Step 4: Test the rule and its enforcement modes 



1. In a new browser tab, open the [Activity Tracker platform logs](https://cloud.ibm.com/observe/activitytracker) to monitor IAM-related events (Frankfurt region).
2. Start a new session of [IBM Cloud Shell](https://cloud.ibm.com/shell) in another browser tab.
3. In the shell, perform the following commands: Set an environment variable to the cloud region you are going to use for the Container Registry, e.g., us or de.

export REGION=us

Set another variable with your initials (or the prefix you picked above):

export YOUR_INITIALS=MI

Now log in to the Container Registry.

ibmcloud cr login
The following example command adds the server-protect service, referred to as "Cloud Block Storage" in IBM Cloud® console, to a network zone.

ibmcloud cbr zone-create --name example-zone-1 --description "Example zone 1" --service-ref service_name=server-protect







 Creating network zones from the console 



1. Determine which resources you want to add to your allowlist.
2. Check the [service references](https://cloud.ibm.com/docs/vpc?topic=vpc-cbrservice-references) section to see if you need to add any service reference to your network zone.
3. Follow these steps to [create context-based restrictions in the console](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create).









 Creating rules 

Within VPC Infrastructure Services each child service needs certain attributes in a context-based rule.

When you use the API, Terraform or the IBM Cloud Command Line Interface (CLI) to create, update, or delete IBM Cloud context-based restrictions, you can specify the target VPC Infrastructure resource by using resource attributes.

See [VPC resource attributes](https://cloud.ibm.com/docs/vpc?topic=vpc-resource-attributes) for the resource attributes that correspond with individual VPC resources.

You can select a resource by entering the ID of the object. Alternatively, you can use the * wildcard to select all applicable resources. For example, the attribute vpcId: sets the context-based restrictions to apply to all VPCs in the account. You can also specify which resource group the policy is applied to in the command.



 Creating rules by using the API 

Review the following example requests to create rules. For more information about the v1/rules API, see the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-rule).

After you create a rule, it might take up to 10 minutes before you can update that rule.
at least one VPN or Direct Link configured<br> * Check whether Virtual Private Cloud (VPC) classic access is disabled<br> * Check whether Virtual Private Cloud (VPC) has no rules in the default security group<br> * Check whether all network interfaces of a virtual server instance have at least one Virtual Private Cloud (VPC) security group attached<br> * Check whether Container Registry image pushes and pulls take place only over private endpoints<br> * Check whether Virtual Servers for VPC instance has the minimum # interfaces<br> * Check whether Virtual Private Cloud (VPC) has no subnet with public gateway attached<br> * Check whether Hyper Protect Crypto Services is accessible only through private endpoints<br> * Check whether Virtual Private Cloud (VPC) security groups have outbound ports that are open only to permitted IP addresses<br> * Check whether Virtual Private Cloud (VPC) is configured with public gateways that are provisionable only within permitted zones<br> * Check whether Cloud Object Storage public access is disabled in IAM settings (not applicable to ACLs managed using S3 APIs)<br> * Check whether a security group other than the default for Virtual Private Cloud is attached to all endpoints<br> * Check whether Virtual Private Cloud (VPC) network access control lists don't allow ingress from 0.0.0.0/0 to RDP port<br> * Check whether App ID redirect URIs are not using localhost or 127.0.0.1<br> * Check whether Virtual Private Cloud (VPC) network access control lists don't allow ingress from 0.0.0.0/0 to SSH port<br> * Check whether Virtual Private Cloud (VPC) network access control lists don't allow egress from 0.0.0.0/0 to any port<br><br><br>
This applies to VPC subnets using RFC-1918 "and" IANA assigned prefixes. As with all custom route additions, the routing table must include a route for each Availability Zone (AZ) requiring connectivity.

Options include:



* If the VPC default (egress) routing table is attached to all VPC subnets, create a route for each IANA prefix or aggregate per zone in the VPC default table with the Delegate-VPC action. This defers to the VPC system routing table for forwarding action.
* If you use custom routing tables, create a route for each IANA prefix or aggregate per zone in each custom routing table with the Delegate-VPC action.



Using IANA ranges works only with custom routes having the Delegate-VPC action, not Delegate. Both custom route actions of Delegate-VPC and Delegate defer to the VPC system routing table. The only difference is that Delegate uses any floating IP or public gateway when forwarding traffic to IANA destinations; Delegate-VPC does not, and assumes that IANA destinations are in the VPC (not the internet).



 Use case 1: VPC connected to an Enterprise with IBM Cloud Direct Link 

Zoom

![VPC connected to an Enterprise with Direct Link use case](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/includes/vpc/includes/vpc/images/vpc-enterprise.png)

VPC connected to an Enterprise with Direct Link use case

VPC A Networks

VPC B Networks



Table 4. 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.0.0.0/8 from an Enterprise through Direct Link 
 172.16.0.0/12 from an Enterprise through Direct Link
To interact with the Regional VPC API by using REST, direct your request to the API endpoint that is associated with the region in which you want to create resources. The region's API endpoint is shown in the previous table. You also can find the endpoints that are associated with the regions by running the following command:

ibmcloud is regions

For example, to get the list of VPCs in the us-south region, run the following command:

curl "https://us-south.iaas.cloud.ibm.com/v1/vpcs?version=$api_version&generation=2" -H "Authorization: $iam_token"





 Get zones by using the CLI 

To get the list of zones available for each region, run the command ibmcloud is zones <region>. For example, to get the list of zones in region us-south, run the following command:

ibmcloud is zones us-south