vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Bring Your Own IP (BYIOP) No BYOIP support. Supports BYOIP for non-overlapping RFC-1918 IP ranges between VPC networks and on-premise networks (see [Routing considerations for IANA-registered IP assignments](https://cloud.ibm.com/docs/vpc?topic=vpc-interconnectivity) for details). 
 Pricing Global routing has a monthly flat rate charge. Free global routing. 
 Automation Full automation for Equinix Exchange and Colt Connect offerings. The rest of the ordering process is partially automated and requires manual configuration. Automation for Dedicated and Connect offerings. Fully automated single-click ordering experience with the providers Equinix, Packet Fabric, Cologix, British Telecom and DE-CIX. For automation information, see [Partner-specific instructions](https://cloud.ibm.com/docs/dl?topic=dl-how-to-order-ibm-cloud-dl-connectinstructions-partner). 
 Connectivity between Direct Link and Transit Gateway Not supported. All MZRs have Direct Link offering support. 
 Bi-directional Forwarding Detection (BFD) You can open an IBM Support case to enable this feature for all Direct Link on Classic offerings. All MZRs have Direct Link offering support. 
 Update BGP ASN and IP You can open an IBM Support ticket to enable this feature for all Direct Link on Classic offerings. All MZRs have Direct Link offering support.
Private network connectivity within IBM Cloud 

For technical, cost, regulatory and/or compliance reasons, you might require all connectivity to, within, and between your VPC infrastructures to be isolated from all public backbone and the internet.

The traffic between our data centers stays within our backbone and in our ASN. Traffic between our data centers does not traverse other networks (ASNs). This includes both public (front-end, internet-facing) and private (back-end) network traffic. IBM® has a global backbone network that circles the globe.

Example use cases of private connectivity include:



1. Instance to instance within an Availability Zone (AZ)
2. Instance to instance between AZs within a single region
3. Instance to instances region to region
4. Connection from a remote network (on-premises) to IBM Cloud®



IBM Cloud supports these topologies with:



* A private backbone for all connectivity between resources deployed in your VPC virtual networks with an AZ and between AZs (this backbone is separate from the public backbone for connectivity using public addressing). IP addresses on the private backbone are non-internet routable, or not announced toward the public backbone or the internet. The private backbone is owned, managed, and operated exclusively by IBM Cloud.
* IBM Cloud Transit Gateway, which meets use cases 1 through 3 by using this private backbone exclusively for connectivity between your virtual networks within a single region, across multiple regions, and to your IBM Cloud classic workloads.
* IBM Cloud Direct Link, which meets use case 4 by providing the ability to attach your remote networks (on-premises) to your virtual networks within IBM Cloud VPC or IBM Cloud classic via this same private backbone.



By default, a VPC is private, and remains private until it is configured to enable public connectivity. For instance, a VPC might be connected to a public gateway or associated with floating IPs.



 Architecture 



 Single-region, multi-zone VPC virtual network 

Zoom

!
Deploying IBM Cloud VPC infrastructure for Power Systems Virtual Server SAP workloads 

As a best practice for SAP that runs on IBM® Power® Systems Virtual Server, three IBM Cloud VPCs are created and three virtual server instances are deployed and configured.



* Access host that is deployed in management VPC is used for the management access to the landscape.
* Host for internet services that are deployed in edge VPC is used to configure the access from Power Systems Virtual Server instances to IBM Cloud services and to the public internet.
* Host for private services that are deployed in workload VPC provides certain management services to the Power Systems Virtual Server instances, like NFS, DNS, NTP.



Zoom

![VPC landing zone for SAP on PowerVS](https://cloud.ibm.com/docs-content/v1/content/f89cc64b006ca59b35404693959c83d5747fee3e/sap/images/step1_manual_VPC-for-PowerVS.svg)

Figure 1. VPC landing zone for SAP on PowerVS



 Deploying IBM Cloud VPC for management services (management VPC) 

IBM Cloud VPC for management services (management VPC) is a mandatory component in the SAP on Power Systems Virtual Server best practices. This service hosts the access hosts to the environment.



* Set up Virtual Private Cloud for management services. For more information, see [Creating a VPC and subnet](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-the-ibm-cloud-consolecreating-a-vpc-and-subnet).
* Take care about the default network prefix. We recommend reducing the default network prefix, so it does not overlap between all your IBM Cloud VPC services.
* Optionally, attach a public gateway to the subnet. With this option, every VPC in the subnet can communicate with the internet. An alternative is to use a floating IP address on virtual system instance instead and enable internet for the instances.





 Deploying access host in management VPC
See [Advanced networking for IBM Cloud VPC](https://www.ibm.com/cloud/architecture/content/course/advanced-networking-for-vpc/) for a one-hour course on VPC networking. BYOIP is supported.
* Power Systems - Network resources include subnets. BYOIP is supported.



* Overlay networks - These networks exist in the IBM Cloud VMware Shared and VMware Dedicated offerings. While technically hosted in the IBM Cloud classic infrastructure environment, these networks are implemented in VMware NSX and under your direct control, including the IP addressing schema. BYOIP is supported. Therefore, overlay networks cannot be routed by the IBM Cloud infrastructure networks; access is through tunnels.
* External:



* Internet - Access the internet through resources that are hosted in any of these three infrastructure environments.
* Remote - Connect remote networks to your IBM Cloud networks. You can use the following services to connect to a remote network:



* Internet VPN - Uses the public internet to connect remote networks and their IBM Cloud networks through a VPN. The VPN is terminated on gateway devices or a service within IBM Cloud.
* Direct Link - Direct Link is a suite of offerings that enable the creation of direct, private connections between your remote, on-premises network and IBM Cloud, without traversing the public internet. For more information, see [Getting started with IBM Cloud Direct Link (2.0)](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl).



You can connect Direct Links to either a local or remote IBM Cloud Transit Gateway, which allows the on-premises network to access all networks that are connected to the IBM Cloud Transit Gateway.









 Use cases 

These use cases describe the following deployment topologies:



* Connecting Power Systems Virtual Server to IBM Cloud classic infrastructure by using IBM Cloud Direct Link (2.0). Typical use cases for this topology are as follows:



* Use IBM Cloud classic x86 resources to create tiered applications across different hardware platforms, that is, x86 application servers and Power database servers.
In IKE Phase 2, the peers use the secure channel from Phase 1 to negotiate parameters for IPsec tunnels. IBM Cloud VPN for VPC supports both IKEv1 (main mode) and IKEv2. See [About policy negotiation](https://cloud.ibm.com/docs/vpc?topic=vpc-using-vpnpolicy-negotiation) for the supported combinations.
* IPsec - Protocol suite that provides secure communication between devices. IBM Cloud VPN for VPC uses UDP Encapsulation of IPsec Encapsulating Security Protocol (ESP) Packets in tunnel mode, which offers authentication and entire packet encryption.
* Modes - IBM Cloud VPN for VPC offers static-route-based, and policy-based VPN modes. With a policy-based VPN, traffic that matches negotiated CIDR ranges passes through the VPN. For a static-route-based VPN, virtual tunnel interfaces are created and any traffic that is routed toward these logical interfaces with custom routes passes through the VPN. Both VPN options provide the same features.
* Perfect Forward Secrecy (PFS) - PFS makes sure that DH-generated keys aren't used again during IPsec renegotiation. If a key is compromised, only data in transit during the protected security association's lifetime is accessible.







 Getting started with VPN gateways 

Before you create a VPN, you must first [create a VPC and one or more subnets](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started) for your VPN and other resources.

Although not required, it is recommended to dedicate a subnet of at least 16 IPs (prefix 28 or lower) for your VPN gateway. If you decide to provision extra resources within the VPN subnet, make sure that there are always at least 4 IPs available for recovery and maintenance tasks for use by the VPN gateway. In addition to the 4 IPs needed by the VPN gateway, up to 5 IPs in a subnet are reserved for internal network use so make sure that the subnet is large enough.

To create a VPN gateway, follow these general steps:



1.
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
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/containers?topic=containers-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/containers?topic=containers-vpc-security-groupvpc-sg-worker-pool).
For example, your VPC cluster can automatically connect to other [IBM Cloud services that support private cloud service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpoint), such as IBM Cloud Container Registry. However, if you need to access IBM Cloud services that support only public cloud service endpoints, you can attach a public gateway to the subnet so that your pods can send requests over the public network. All egress is permitted for worker nodes on a subnet with an attached public gateway, but all ingress is still blocked.

If you deploy apps in your cluster that must receive traffic requests from the internet, you can [create a VPC load balancer](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas) to expose your apps. To allow ingress network traffic to your apps, you must configure your VPC load balancer for the ingress network traffic that you want to receive.

Security groups are applied to your VPC instance and VPC ALBs by default. For more information, see [Controlling traffic with VPC security groups](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group).





 What is network segmentation and how can I set it up for a VPC cluster? 

Network segmentation describes the approach to divide a network into multiple subnetworks. You can group apps and related data to be accessed by a specific group in your organization. Apps that run in one subnetwork can't see or access apps in another subnetwork. Network segmentation also limits the access that is provided to an insider or third-party software and can limit the range of malicious activities.

IBM Cloud Kubernetes Service provides IBM Cloud VPC subnets that ensure quality network performance and network isolation for worker nodes. A VPC subnet consists of a specified private IP address range (CIDR block) and configures a group of worker nodes and pods as if they were attached to the same physical wire. VPC subnets are dedicated to your IBM Cloud account and not shared across IBM customers.
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
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/containers?topic=containers-vpc-security-group&interface=uivpc-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/containers?topic=containers-vpc-security-group&interface=uivpc-sg-worker-pool).
From IBM Cloud Identity and Access Management (IAM), create an authorization between the Virtual Private Cloud (VPC) Infrastructure (source service) > Image Service for VPC (resource type) and Cloud Object Storage (target service). For more information, see [Create an authorization](https://cloud.ibm.com/docs/iam?topic=iam-serviceauthserviceauth).

Important: The configuration must be set up as this example or permissions can fail.

Zoom

![Figure showing example IAM authorization.](https://cloud.ibm.com/docs-content/v1/content/b6066ebcc4ff31f2a8b558531f2ee791d108a7e1/cloud-pak-multicloud-management/images/service_auth_vpc.png)

Figure 5. Example IAM authorization
4. Create a generation 2 Virtual Private Cloud (Must be generation 2). For more information, see [Create a VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-startedcreate-and-configure-vpc)

a. Create a VPC - The VPC must be in the same resource group and region as your bucket.

b. Create subnets in one or more zones. You can create subnets in suggested prefix ranges or in your own IP ranges that you bring to IBM Cloud.

c. Attach a public gateway if you want to allow all resources in a subnet to communicate with the public internet.

Zoom

![Figure showing example VPC.](https://cloud.ibm.com/docs-content/v1/content/b6066ebcc4ff31f2a8b558531f2ee791d108a7e1/cloud-pak-multicloud-management/images/vpc_details.png)

Figure 6. Example VPC
5. Configure an access control list (ACL) to limit the subnet's inbound and outbound traffic.
To create other VPC resources, such as ACL, load balancer, and other resources, see [Using the IBM Cloud console to create VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-the-ibm-cloud-console).







 Deploying IBM Cloud VPC for edge services (edge VPC) 

IBM Cloud VPC for edge services (edge VPC) is a mandatory component in the SAP on IBM Power Virtual Services best practices. This service hosts the internet-facing SAP workloads.



* Set up IBM Cloud VPC for management services. For more information, see [Creating a VPC and subnet](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-the-ibm-cloud-consolecreating-a-vpc-and-subnet).
* Take care about the default network prefix. We recommend reducing the default network prefix, so it does not overlap between all your IBM Cloud VPC services.
* Attach a public gateway to the subnet. Every VPC in the subnet can communicate with the internet. An alternative is to use a floating IP address on the virtual system instance instead and enable internet for the instances.





 Deploying host for internet services in edge VPC 

Host for internet services is a mandatory component in the SAP on Power Systems Virtual Server best practices. This virtual server instance hosts mandatory proxy server. Use the following steps to deploy a host for basic management services.

The following example setup uses open ports for standard SQUID proxy server that is provided by Linux distributions. If you use another proxy software or custom configurations, setup might vary.



1. Create a security group for basic management services as described [Configuring the security group for the instance](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-the-ibm-cloud-consoleconfiguring-the-security-group). Specify following rules:

Inbound security group rules

Outbound security group rules



Table 5.
The IBM Cloud for Financial Services profile provides a tailored set of goals that are mapped to the [IBM Cloud Framework for Financial Services control requirements](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-aboutframework-control-requirements). This profile should always be used when leveraging the [VPC reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-about).

In addition, if you are using Red Hat OpenShift on IBM Cloud (whether in the VPC reference architecture or the [Satellite reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-satellite-architecture-about)), then you should leverage the [Red Hat OpenShift on IBM Cloud Compliance Operator (OSCO)](https://github.com/openshift/compliance-operator) via the [OSCO integration](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-setup-osco) with SCC.

To start evaluating your resources, see the [Getting started with Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-getting-started)





 Compliance best practices for Financial Services Validated services 

The following table provides references to additional information for managing security and compliance for each service in the reference architecture.



Table 1. Managing security and compliance for IBM Cloud services in the reference architectures

 Category VPC reference architecture Satellite reference architecture Optional for both 

 Core <br><br> * [VPC infrastructure services](https://cloud.ibm.com/docs/vpc?topic=vpc-manage-security-compliance)[1]<br><br><br> <br><br> * [Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-complianceplatform-compliance)<br><br><br>
Cross-account encryption for file storage resources 

File Storage for VPC supports cross-account customer-managed encryption. IBM Cloud® Virtual Private Cloud customers can authorize access to a customer root key (CRK) for users of another account. Then, those users can use the CRK to encrypt a new file share in their own account.

IBM Cloud® File Storage for VPC is available for customers with special approval to preview this service in the Frankfurt, London, Madrid, Dallas, Toronto, Washington, Sao Paulo, Sydney, Osaka, and Tokyo regions. Contact your IBM Sales representative if you are interested in getting access.



 About cross account key access and use 

Customer root keys in one account can be made available to users of another account to use when they create an encrypted file share.

A privileged user from the account that owns the root key must [invite the user](https://cloud.ibm.com/docs/account?topic=account-iamuserinv) of the second account, and set the IAM delegated policy to the root keys. For more information, see [Granting access to keys with Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-grant-access-keys) and [Granting access to keys with Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-grant-access-keys).

If the invited user is already a member of IBM Cloud, they receive an invitation link in their notifications and by email. The user in the account that's creating the file share can be the same user as the owner of the root key in the other account.

When the invited user makes the [API request](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-byok-cross-acct-key-filebyok-cross-key-acct-create-API) to create the encrypted file share in their own account, they can specify the CRN of the root key of the first account in the encryption_key property.





 Restrictions
: IBM Cloud® File Storage for VPC is available to customers with special approval to preview this service in the Washington, Dallas, and Frankfurt regions.





 17 August 2021 

Instance Identifier Update
: The instance identifier (ID) now includes the SMBIOS system-uuid as a portion of the ID. The ID, including the SMBIOS system-uuid portion, is static and persists for the lifecycle of the virtual server instance until that virtual server instance is deleted. For more information, including how to retrieve this information from within your virtual server, see [Retrieving the virtual server instance identifier](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-virtual-server-instancesretrieve-VSI-instance-identifer) section in Managing virtual server instances.

Placement groups (GA)
: Placement groups for IBM Cloud® Virtual Private Cloud are used to create placement group strategies for managing high availability workloads. A placement group contains virtual server instances that share a common placement strategy. Placement strategies influence the physical placement of select VPC resources to meet certain workload demands. For more information about placement groups, see [About placement groups](https://cloud.ibm.com/docs/vpc?topic=vpc-about-placement-groups-for-vpc).





 11 August 2021 

Auto scale supports data volumes and private catalog
: Instance groups now support by using an instance template that includes one or more data volumes. In addition, instance groups are now supported in private catalog. For more information about instance groups, see [Creating an instance group for auto scaling](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-auto-scale-instance-group).





 9 August 2021 

LinuxONE (s390x processor architecture)
: You can now create virtual server instances on LinuxONE (s390x processor architecture) in IBM Cloud in the Tokyo region. For more information about available LinuxONE (s390x processor architecture) profiles, see [s390x instance profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-vs-profiles).