vania-janet/multiturn-rag-retrieval-data huggingface dataset:
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 
 13.0.0.0/8 from an Enterprise through Direct Link 



VPC A Default (Egress) Routing Table

VPC B Default (Egress) Routing Table



Table 6. VPC A Default (Egress) Routing Table

 Destination Action Next Hop Location 

 13.0.0.0/8 Delegate-VPC <br><br> * <br><br><br> Dallas 1 
 13.0.0.0/8 Delegate-VPC <br><br> * <br><br><br> Dallas 2 
 13.0.0.0/8 Delegate-VPC <br><br> * <br><br><br> Dallas 3 







 Use case 2: VPC-to-VPC connected with IBM Cloud Transit Gateway 

Zoom

![VPC-to-VPC connected with Transit Gateway use case](https://cloud.ibm.com/docs-content/v1/content/b698ea8660e1f51664f7479f870bbf8840335d06/dl/includes/vpc/includes/vpc/images/vpc-vpc-transit-gateway.png)

VPC-to-VPC connected with Transit Gateway

VPC A Networks

VPC B Networks

VPC Z Networks



Table 8. 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)
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 
 13.0.0.0/8 from an Enterprise through Direct Link 



VPC A Default (Egress) Routing Table

VPC B Default (Egress) Routing Table



Table 6. VPC A Default (Egress) Routing Table

 Destination Action Next Hop Location 

 13.0.0.0/8 Delegate-VPC <br><br> * <br><br><br> Dallas 1 
 13.0.0.0/8 Delegate-VPC <br><br> * <br><br><br> Dallas 2 
 13.0.0.0/8 Delegate-VPC <br><br> * <br><br><br> Dallas 3 







 Use case 2: VPC-to-VPC connected with IBM Cloud Transit Gateway 

Zoom

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

VPC-to-VPC connected with Transit Gateway

VPC A Networks

VPC B Networks

VPC Z Networks



Table 8. 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)
* ibmcloud is vpc-routing-table-create vpc-doloremque-6364-us-east --name test-vpc-cli-routing-tb2 --direct-link-ingress true --internet-ingress false --transit-gateway-ingress false --vpc-zone-ingress false
* ibmcloud is vpc-routing-table-create 979b4bc6-f018-40a2-92f5-0b1cf777b55d --name test-vpc-cli-routing-tb1 --direct-link-ingress false --internet-ingress false --transit-gateway-ingress false --vpc-zone-ingress true
* ibmcloud is vpc-routing-table-create my-vpc --name my-vpc-routing-table --accept-routes-from-resource-type-filters vpn_server,vpn_gateway Create a routing table with resource type filter.







 Command options 



* VPC: ID or name of the VPC.
* --name: Name of the VPC routing table.
* --direct-link-ingress, --direct-link: If set to "true", this routing table is used to route traffic that originates from Direct Link to this VPC. For the routing to succeed, the VPC must not already have a routing table with this property set to "true". One of: false, true.
* --internet-ingress, --internet: Indicates whether this routing table is used to route traffic that originates from the internet. Updating to "true" selects this routing table, provided no other routing table in the VPC already has this property set to "true". Updating to "false" deselects this routing table. One of: false, true.
* --transit-gateway-ingress, --transit-gateway: If set to "true", this routing table is used to route traffic that originates from Transit Gateway to this VPC. For the routing to succeed, the VPC must not already have a routing table with this property set to "true". One of: false, true.
ibmcloud is vpc-routing-table-update VPC ROUTING_TABLE [--name NEW_NAME] [--direct-link-ingress false | true] [--internet-ingress, --internet false | true] [--transit-gateway-ingress false | true] [--vpc-zone-ingress false | true] [--accept-routes-from-resource-type-filters, --ar-rtf vpn_server | vpn_gateway | --clean-all-accept-routes-from-filters, --cl-arf] [--output JSON] [-q, --quiet]



 Command examples 



* ibmcloud is vpc-routing-table-update 72b27b5c-f4b0-48bb-b954-5becc7c1dcb3 72b27b5c-f4b0-48bb-b954-5becc7c1d456 --name my-renamed-vpc-routing-table --output JSON
* ibmcloud is vpc-routing-table-update my-vpc my-vpc-routing-table --name my-renamed-vpc-routing-table --output JSON
* ibmcloud is vpc-routing-table-update vpc-doloremque-6364-us-east test-vpc-cli-routing-tb2 --direct-link-ingress true --internet-ingress false --transit-gateway-ingress true --vpc-zone-ingress false
* ibmcloud is vpc-routing-table-update 979b4bc6-f018-40a2-92f5-0b1cf777b55d 27415d55-9d3b-4adb-a993-236ef59a45ec --direct-link-ingress false --internet-ingress false --transit-gateway-ingress false --vpc-zone-ingress false







 Command options 



* VPC: ID or name of the VPC.
* ROUTING_TABLE: ID or name of the VPC routing table.
In the table above 10.1.0.196 zone Dallas 1 and 10.2.0.196 zone Dallas 2, etc. You can observe this using the IBM Cloud console.



1. Open [Virtual server instances for VPC](https://cloud.ibm.com/vpc-ext/compute/vs) to find the fw instances and associated Reserved IP (click the Name column header to sort).
2. Match them up with the table above to verify the next hop relationship.







 VPC Address Prefixes 

Transit Gateway learn routes in the attached VPCs through the [VPC Address Prefixes](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-addressing-plan-design). But how does a spoke learn the route to the enterprise (192.168.0.0/16)? And how does the enterprise learn the route to a spoke? By adding phantom VPC address prefixes to the transit VPC.

The transit VPC zone in the diagram has the additional address prefixes:



* 192.168.0.0/24 Dallas 1.
* 192.168.1.0/24 Dallas 2.
* 192.168.2.0/24 Dallas 3.



To observe this:



1. Open the [VPCs](https://cloud.ibm.com/vpc-ext/network/vpcs) in the IBM Cloud.
2. Select the transit VPC and notice the Address prefixes displayed.
3. Find the additional address prefixes for the enterprise CIDR blocks and note the associated zones.



Also notice that the Address prefix for that transit VPC itself:



* 10.1.0.0/16 Dallas 1.
* 10.2.0.0/16 Dallas 2.
* 10.3.0.0/16 Dallas 3.



The transit VPC will only use a subset of each zone:



* 10.1.0.0/24 Dallas 1.
* 10.2.0.0/24 Dallas 2.
* 10.3.0.0/24 Dallas 3.
* ibmcloud is vpc-routing-table-route-create vpc1001 routing-table-vpc1001-1-name --zone us-east-3 --destination 10.2.2.0/24 --action deliver --priority 3 --next-hop vpn-connection-vel-4573-us-east --vpngw aaa-default-vpn-gateway-1 --name vpc-route-cli-demo-1001







 Command options 



* VPC: ID or name of the VPC.
* ROUTING_TABLE: ID or name of the VPC routing table.
* --zone: Name of the zone.
* --action: The action to perform with a packet that matches the route. One of: delegate_vpc, delegate, deliver, drop.
* --destination: The destination CIDR of the route. At most, two routes per zone in a table can have the same destination, and only if both routes have an action of deliver.
* --priority: The route's priority. Smaller values have higher priority. Values can range between 0-4. (default: 2).
* --next-hop: If the action is deliver, then the IP address, VPN connection ID, or name of the next-hop that packets are delivered to. For other action values, it must be omitted or specified as 0.0.0.0.
* --vpngw: ID or name of the VPN gateway. This option is required only if the next-hop is specified as VPN connection in name format.
* --name: Name of the VPC routing table.
* --output: Specify output format, only JSON is supported. One of: JSON.
* -q, --quiet: Suppress verbose output.



--------------------







 ibmcloud is vpc-routing-table-route-update 

Update a VPC route.
* API







 API example - Connecting two VPCs using VPN 

The following API example describes how to connect two VPCs by creating a VPN gateway in each VPC. A VPN gateway can connect all the subnets in the zone where it is deployed. Therefore, having a VPN gateway in each zone that you want to interconnect makes the subnets in both zones act as if they were a single network. The IP addresses of the subnets in the two VPCs must not overlap.

You can use a VPN gateway to connect two VPCs. However, it is recommended to use IBM Cloud Transit Gateway for VPC-to-VPC connectivity. For more information, see [Getting started with IBM Cloud Transit Gateway](https://cloud.ibm.com/docs/transit-gateway).

The following diagram shows how to interconnect three VPCs; the following example shows you how to connect only the first two. You can repeat the steps to connect more VPCs.

Zoom

![Interconnecting VPCs by using VPN gateways](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/vpc-vpn.svg)

Figure 1: Interconnecting VPCs by using VPN gateways

The following example assumes that:



1. You already created VPCs, subnets, and virtual server instances. For more information about creating VPC resources, see [Getting started with Virtual Private Cloud (VPC)](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started).
2. You set up your [API environment](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environmentapi-prerequisites-setup) and initialized all the variables needed.



You can also create a VPN gateway and add VPN connections by using the UI.
* --name: Name of the VPC routing table.
* --output: Specify output format, only JSON is supported. One of: JSON.
* -q, --quiet: Suppress verbose output.



--------------------







 ibmcloud is vpc-routing-table-route-update 

Update a VPC route.

ibmcloud is vpc-routing-table-route-update VPC ROUTING_TABLE ROUTE [--name NEW_NAME] [--priority PRIORITY] [--next-hop NEXT_HOP --vpngw VPNGW]] [--output JSON] [-q, --quiet]



 Command examples 



* ibmcloud is vpc-routing-table-route-update 72b27b5c-f4b0-48bb-b954-5becc7c1dcb3 72b27b5c-f4b0-48bb-b954-5becc7c1d456 72b27b5c-f4b0-48bb-b954-5becc7c1d4ef --name my-vpc-route --output JSON
* ibmcloud is vpc-routing-table-route-update vpc1001 routing-table-vpc1001-rtable011-id my-vpc-route --priority 4 --next-hop 10.1.1.1 --name vpc-route-cli-1
* ibmcloud is vpc-routing-table-route-update vpc1001 routing-table-vpc1001-1-name vpc-route-cli-demo-1001 --priority 3 --next-hop 541c6bbf-6109-44bd-b2c9-176c6e11bc59 --vpngw aaa-default-vpn-gateway-1 --name vpc-route-cli-demo-1003







 Command options 



* VPC: ID or name of the VPC.
* ROUTING_TABLE: ID or name of the VPC routing table.
Architecture pattern for a bastion VPC to manage vCenter Server instance in Classic 

This architecture pattern presents Client VPN based connectivity to a vCenter Server instance provisioned in IBM Cloud® classic infrastructure. This solution uses a bastion VPC with [client-to-site VPNaaS](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-client-to-site-overview&interface=ui) and a connecting [IBM Cloud Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-about), or alternatively using a VPC provisioned with [classic connectivity](https://cloud.ibm.com/docs/vpc?topic=vpc-setting-up-access-to-classic-infrastructure). [IBM Cloud DNS Services](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-getting-started) are used in VPC with a custom resolver.



 Deploying a bastion VPC for managing vCenter Server deployment in Classic 

The following diagram presents an overview for an architecture pattern for deploying bastion VPC to manage vCenter Server deployment in Classic.

Zoom

![Architecture overview for a bastion VPC with VMware Solutions](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-bastion-vpc.svg)

Figure 1. Architecture overview for a bastion VPC with VMware® Solutions

This architecture pattern deployment is summarized as follows:



1. [Create a VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-vpc-resources-with-cli-and-api&interface=cli) for the Bastion hosts.
For single-digit months or dates, such as January 1st, the version should look like 2019-01-01. The date given in the version parameter must be later than 2019-01-01 but before the current date. Check out these [API examples](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-creating-a-vpc-using-the-rest-apis) for how to provide the version parameter.





 network_conflict 

Message: CIDR conflicts with existing Address Prefix in VPC.

You might see this message if you provided a network CIDR that conflicts with an existing network CIDR in the same IP space.

To find the existing CIDRs in Address Prefixes for the VPC, run the API command GET /v1/vpcs/<vpc-id>/address_prefixes and look at the cidr values of the response. Check the value of cidr to make sure that the CIDR you've provided is not in use by other Address Prefixes.

If you are using the CLI, run the command ibmcloud is vpc-addrs <vpc-id> and check the value of CIDR Block for conflicts.

To find the existing CIDRs in subnets, run the API command GET /v1/subnets to list all the subnets for the VPC. Then, run the API command GET /v1/subnets/<subnet-id> for each subnet in the VPC and check the value of ipv4_cidr_block in the response. Check the value of ipv4_cidr_block to make sure that the CIDR you've provided is not in use by other Address Prefixes.

If you are using the CLI, run the command ibmcloud is subnets to list all the subnets for the VPC. Then, run the command ibmcloud is subnet <subnet-id> for each subnet in the VPC, and check for conflicts with the value of IPv4 CIDR in the CLI output.





 new_account_provisioning_disabled 

Message: Provisioning of resources for accounts new to VPC are disabled for VPC Gen1.
This example illustrates creating a VPC connection named vpc-connection using vpcCRN="crn:v1:bluemix:public:is:us-south:a/3aa0a9999a1a46258064d84f7f447920::vpc:r134-f87014d5-87d2-46d1-9999-24683082f6bc":

ibmcloud tg cc $gateway --name vpc-connection --network-id $vpcCRN --network-type vpc

Create Classic connection named classic-conn.

ibmcloud tg cc $gateway --name classic-conn --network-type classic









 Adding a connection with the API 

To add a connection with the API, follow these steps:



1. Set up your [API environment](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environmentapi-prerequisites-setup).
2. Store any additional variables to be used in the API commands.





 Request 

To add a connection to the transit gateway, adjust the following parameters:



Table 1. Path parameters for adding a connection

 Path parameters Details 

 transit_gateway_id <br>Required <br>string The transit gateway identifier 





Table 2. Query parameters for adding a connection

 Query Parameters Details 

 version <br>Required <br>string Requests the version of the API as of a date in the format YYYY-MM-DD. Any date up to the current date may be provided. Specify the current date to request the latest version. <br>Possible values: Value must match regular expression ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ 
 Request Body <br>Required <br>TransitGatewayConnectionTemplate The connection template 
 network_type <br>Required <br>string Defines the type of network being connected to. For access to gre_tunnel connections, contact IBM support.
For more information, see the mounting information for [Red Hat](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-vpc-mount-RHE), [CentOS](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-mount-centos), and [Ubuntu](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-vpc-mount-ubuntu) Linux distributions, or [z/OS](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-vpc-mount-zos) systems.





 What is the minimum NFS version supported? 

File Storage for VPC requires NFS versions v4.1 or higher.





 What features are supported in this release? 

In this release, you can:



* Create a file share.
* Mount a file share to one or multiple virtual server instances across multiple VPCs within the same zone or across zones.
* Restrict access to a specific virtual server instance when mounting a file share by using security groups.
* Enable end-to-end encryption in transit for file share data.
* Delete a file share.
* Delete all mount targets or delete a single mount target. When you delete one or several mount targets, the instances that are mounting the file share for the VPCs where the mount target is deleted can't access the file share.
* List file shares and mount targets.
* Update file share and mount target name.
* Create replication between the source file share and a replica file share.
* Fail over to a replica file share when the source share is compromised. Fall back to the original share when the issue is resolved.
* Add, manage, and delete file share user tags. Create and manage access management tags.







 Who do I contact to help with any issues? What information do I need to provide?
"crn": "crn:v1:public:resource-controller::a/e2f80b84-bc75-4f53-8737-8193ef1d1a7b::resource-group:e96d1fa9-76f2-4c87-a737-dbab3a947b24",
"href": "https://resource-controller.cloud.ibm.com/v2/resource_groups/e96d1fa9-76f2-4c87-a737-dbab3a947b24",
"id": "e96d1fa9-76f2-4c87-a737-dbab3a947b24",
"name": "Default"
},
"resource_type": "share",
"size": 4800,
"mount_targets": [],
"zone": {
"href": "https://us-south.iaas.cloud.ibm.com/v1/regions/us-south/zones/us-south-1",
"name": "us-south-1"
}
}
Show more





 Create a file share and mount target together with the API 

The following example request creates a file share that has VPC-wide access mode and a mount target that can be used by every virtual server instance in the specified VPC. It also adds [user tags](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-managing&interface=apifs-add-user-tags) to the share.

Access to the mount target is VPC wide; all instances in the VPC have access to this file share. You can also restrict access to a specific virtual server instance in the VPC by specifying a virtual network interface in the mount target definition.
* ibmcloud is vpc-routing-table-route-create 72b27b5c-f4b0-48bb-b954-5becc7c1dcb3 72b27b5c-f4b0-48bb-b954-5becc7c1d456 --name my-vpc-route --action delegate --zone us-south-1 --destination 10.2.2.0/24 --output JSON
* ibmcloud is vpc-routing-table-route-create 72b27b5c-f4b0-48bb-b954-5becc7c1dcb3 72b27b5c-f4b0-48bb-b954-5becc7c1d456 --name my-vpc-route --action drop --zone us-south-1 --destination 10.2.2.0/24 --output JSON
* ibmcloud is vpc-routing-table-route-create vpc1001 routing-table-vpc1001-rtable011-id -name my-vpc-route --action deliver --zone us-east-3 --destination 10.2.2.0/24 --priority 1 --next-hop 10.0.0.2
* ibmcloud is vpc-routing-table-route-create vpc1001 routing-table-vpc1001-1-name --zone us-east-3 --destination 10.2.2.0/24 --action deliver --priority 3 --next-hop vpn-connection-vel-4573-us-east --vpngw aaa-default-vpn-gateway-1 --name vpc-route-cli-demo-1001







 Command options 



* VPC: ID or name of the VPC.
* ROUTING_TABLE: ID or name of the VPC routing table.
* --zone: Name of the zone.
* --action: The action to perform with a packet that matches the route. One of: delegate_vpc, delegate, deliver, drop.
"id": "549192f1-d238-42bd-8657-b6034a08f04e"
}
}'

The following request creates a mount target for an existing file share with the access_control_mode set to vpc, specifying API version 2023-07-11 or later. All virtual server instances within the specified VPC can mount and access the file share.

curl -X POST "$vpc_api_endpoint/v1/shares/$share_id/mount_targets?version=2023-07-11&generation=2&maturity=beta" -H "Authorization: Bearer $iam_token" -H 'Content-Type: application/json' -d '{
"name": "my-mount-target-name1",
"vpc": {
"id": "6e01bc24-4a6e-4a0c-a1bd-4caa0c8159e7"
},
}

The following request creates a mount target for an existing file share with the access_control_mode set to security group, specifying API version 2023-07-11 or later. The request specifies the virtual_network_interface that's going to be attached to the mount target by providing a subnet and security group values.

curl -X POST "$vpc_api_endpoint/v1/shares/$share_id/mount_targets/?version=2023-07-11&generation=2&maturity=beta" -d '{
"virtual_network_interface": {
"subnet": {
"id": "1a0b3d75-8a62-4c78-9263-f9bcd25a8759"
},
"security_groups": [
{
"id": "b2599112-7027-480e-ad1b-fd917d2fcb84"
}
]
},
}'
The speed and reliability of Direct Link extends your organization’s data center network and offers more consistent, higher-throughput connectivity, keeping traffic within the IBM Cloud network. When using Direct Link, a private [Application Load Balancer for VPC (ALB)](https://cloud.ibm.com/docs/vpc?topic=vpc-load-balancers) is used to distribute traffic among multiple server instances within the same region of your VPC.

The following diagram shows the Direct Link connection pattern.

Zoom

![Application provider on-premises to management VPC by using Direct Link](https://cloud.ibm.com/docs-content/v1/content/9ac5c38b41e0aa1cb4ccc6cc7f547751ec805221/framework-financial-services/vpc/images/network-connectivity/provider-to-management-vpc/vpc-architecture-provider-on-prem-to-management-vpc-DL.svg)

Figure 1. Application provider on-prem to management VPC using Direct Link

For more information, see:



* [Interconnecting your VPC that uses IBM Cloud offerings](https://cloud.ibm.com/docs/vpc?topic=vpc-interconnectivity)
* [Getting started with Direct Link](https://cloud.ibm.com/docs/dl/getting-started?topic=dl-get-started-with-ibm-cloud-dl)
* [Ordering IBM Cloud Direct Link Dedicated](https://cloud.ibm.com/docs/dl?topic=dl-how-to-order-ibm-cloud-dl-dedicated)
* [Integrating with Virtual Private Endpoint for VPC](https://cloud.ibm.com/docs/dl?topic=dl-vpe-for-ibm-cloud-direct-link)







 VPN for VPC 

An alternative connectivity pattern is to use the VPN for VPC service to securely connect from your private network to the management VPC.
It is only required to specify the unique resource by name inside this VPC.
* --health-monitor-url: The health check URL path. Applicable only if the HEALTH_TYPE is http or https.
* --health-monitor-port: The health check port number. If specified, the specified ports in the server member resources are overridden.
* --session-persistence-type: The session persistence type. One of: source_ip, http_cookie, app_cookie.
* --session-persistence-cookie-name: Session persistence cookie name. This option is applicable only to app_cookie type.
* --proxy-protocol: The proxy protocol setting for this pool. Proxy protocol is supported only for application load balancers. One of: disabled, v1, v2.
* --members: MEMBERS_JSON|@MEMBERS_JSON_FILE, members in JSON or JSON file.
* --output: Specify output format, only JSON is supported. One of: JSON.
* -q, --quiet: Suppress verbose output.



--------------------







 ibmcloud is load-balancer-pool-delete 

Delete one or more pools from a load balancer.

ibmcloud is load-balancer-pool-delete LOAD_BALANCER (POOL1 POOL2 ...) [--vpc VPC] [--output JSON] [-f, --force] [-q, --quiet]



 Command options 



* LOAD_BALANCER: ID or name of the load balancer.
* POOL1: ID or name of the pool.
* POOL2: ID or name of the pool.
* --vpc: ID or name of the VPC. It is only required to specify the unique resource by name inside this VPC.
* --output: Specify output format, only JSON is supported. One of: JSON.
* --force, -f: Force the operation without confirmation.
* -q, --quiet: Suppress verbose output.