vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information, refer to [Interconnecting VPCs](https://cloud.ibm.com/docs/vpc?topic=vpc-interconnectivity&interface=cliinterconnecting-vpcs).



VLANs



* Can I move an existing device to a new VLAN?

Existing compute devices, such as a virtual server instance (VSI) or a bare metal, cannot be moved to a new VLAN. A new VSI or bare metal must be provisioned in the new VLAN and deprovisioned accordingly. Single VLAN firewalls cannot be moved to a new VLAN either. Multi VLAN firewalls can be attached to the new VLAN and then detached from the previous VLAN. Refer to the specific offering documentation for capabilities and limitations.
* Is there a way to specify which VLAN I want to use for my device when I order it?

Yes, a specific VLAN can be selected during the ordering process. This option is available at the end of the device order form. A private VLAN is selected, followed by a public VLAN. Remember that a subnet selector is presented for each VLAN, and that this selection is optional. Select a subnet only if you have reason to do so because selecting a subnet that lacks available IP addresses negatively impacts the fulfillment of the device. See the [Subnet FAQ](https://cloud.ibm.com/docs/subnets?topic=subnets-faq) for more details.

The selected VLAN must be located in the same data center as the device. We cannot assign a device to a VLAN that is in a different data center.
* How many devices can be assigned to a single VLAN?

Currently, no limit exists for the number of devices that are associated with a single VLAN at any time. However, when a hardware firewall is associated with a VLAN, the type of firewall might impose restrictions on the number of devices that reside on the VLAN.
* What kinds of devices are assigned to a VLAN?

Any device that has a network connection is associated with a VLAN.
Although the customer-managed NSX Edge is connected to the public VLAN, security measures are in place to ensure that it does not pose a security risk. The following security measures are in place:



* A firewall rule is in place to allow only outgoing traffic from the private subnet range of IP addresses.
* A SNAT rule (disabled by default) is in place to convert all IP addresses from the private subnet to a single IP address on the public subnet.
* Remote access for the customer-managed NSX Edge appliance is disabled.
* Passwords for accessing the customer-managed NSX Edge from the private network are randomized and encrypted.



* How do I choose the data centers for my instances?

The instance deployments have strict physical infrastructure requirements, which vary among IBM Cloud data centers. When you place your instance order, the available data centers are listed within regions and you can select the one that you want from the list.

For more information, see the IBM Cloud data center availability sections in:



* [Requirements and planning for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_planning)
* [Requirements and planning for VMware vSphere](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vs_planning)



* How long does it take for my instance to be deployed?

You can check the status of the instance deployment by viewing the deployment history on the instance details page from the IBM Cloud for VMware Solutions console.
* How do I add a public network to a vCenter Server instance ordered as private network only?

Cancel the order, and then place a new order with the configuration that you want for a public IP address or public VLAN. You cannot add a public network after it was ordered as private network only.
* How do I request a RAM upgrade for ESXi hosts?

The account owner can increase the RAM on ESXi servers by following these steps:



1. Log in to the IBM Cloud console and go to the device list.
2. Select the ESXi server to be modified.
// Set up the various event listeners for the server and log their output
server.on('error', function(err) {
console.log('Server error', err);
});

server.on('close', function() {
console.log('Server closing');
});

server.on('tlsClientError', function(err) {
console.log('Server tlsClientError', err);
});

server.listen(8999);
Show more





 Update the Client Access Control List 

Before testing my application, I need to make sure the ACL on my Client is configured appropriately. I have added localhost:8999 to my ACL:

--------------------------------------------------------------------
-- Secure Gateway Client Access Control List --

Connections to unlisted rules are currently: denied

hostname:port path value
localhost:8999 Allow
--------------------------------------------------------------------





 Testing the connection 

Now that my application, my local server, and my Client have all been configured, I get the following output from my application and my Client:



 Application 

Client connected, authorized: true
Client data: Successful connection message from the server
Client connection closing





 Secure Gateway Client 

[2017-04-07 12:22:42.363] [INFO] (Client ID Nn5TJ34LyVQ_qCB) Connection 1 is being established to localhost:8999
* [Why doesn't the retention command show all the images?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-image-list-retention)
* [Why do I get an error when I'm restoring an image?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-image-restore)
* [Why aren't all the tags restored when I restore by digest?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-image-restore-digest)
* [Why do I get a manifest unknown error?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-manifest-unknown)
* [Why do I get a manifest type error when I tag my image?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-manifest-error-type)
* [Why do I get a manifest version error?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-manifest-error-version)
* [Why do I get a manifest list invalid error?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-manifest-list-error)







 Troubleshooting networking 

Troubleshoot networking problems.



* [Why can't I access the registry through a custom firewall?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-firewall)
* [Why can't I connect to Container Registry?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-connect)







 Troubleshooting Portieris 

Troubleshoot Portieris problems.



* [Why don't my pods restart after my workers were down?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-pods)
* [Key deletion or disable](https://cloud.ibm.com/docs/schematics?topic=schematics-secure-datakey-delete)
* [Key enable or restore](https://cloud.ibm.com/docs/schematics?topic=schematics-secure-datakey-enable)



* [What technical information is stored in Schematics?](https://cloud.ibm.com/docs/schematics?topic=schematics-secure-datati-data)
* [Where is my information stored?](https://cloud.ibm.com/docs/schematics?topic=schematics-secure-datapi-location)
* [How is my information encrypted?](https://cloud.ibm.com/docs/schematics?topic=schematics-secure-datapi-encrypt)
* [How can I delete my information?](https://cloud.ibm.com/docs/schematics?topic=schematics-secure-datadelete-data)



[Firewall access - allowed IP addresses](https://cloud.ibm.com/docs/schematics?topic=schematics-allowed-ipaddressesallowed-ipaddresses)



* [Schematics IP addresses](https://cloud.ibm.com/docs/schematics?topic=schematics-allowed-ipaddressesipaddresses)







 Creating an IBM Cloud Kubernetes Service cluster on VPC infrastructure 

[Creating an IBM Cloud Kubernetes Service cluster on VPC infrastructure](https://cloud.ibm.com/docs/schematics?topic=schematics-provisioning-terraform-templateprovisioning-terraform-template)



* [Description](https://cloud.ibm.com/docs/schematics?topic=schematics-provisioning-terraform-templateprovisioning-desc)
[Gateway cluster with NSX-T](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-nsx-t-edge-services-cluster.svg)

Figure 1. Gateway cluster with NSX-T

The following list is a summary of the architecture pattern deployment:



1. You can optionally deploy a gateway cluster to host Juniper vSRX or your own routing or firewall device. This cluster is attached to both IBM Cloud private and public networks through transit networks.
2. vSRX or the third-party device can route assigned VLANs through it. You can choose the VLANs to be routed through it from IBM Cloud portal. You must configure the required VLAN interfaces and IP addresses to the devices, the firewall zones, the rules, and the policies.
3. If you route your management VLAN through the firewall, you can also secure your management workloads, such as vCenter and NSX-T managers. Ensure that you allow the traffic for your management.
4. Your workload T0 is attached to IBM Cloud private network. If you route this VLAN through the firewall, add the required rules on both the firewall and T0.
5. Your workload T0 is attached to IBM Cloud public network. If you route this VLAN through the firewall, add the required rules on both the firewall and T0.
6. Alter the automation-deployed routes if you need to customize the routing behavior, or establish dynamic routing between your T0 and the vSRX (or third-party device).







 Ordering new VLAN for gateway cluster with NSX-T 

In some designs, extra VLANs might be preferred or needed, especially with a gateway cluster. In IBM Cloud, you can provision extra VLANs for your classic NSX-T network deployment.
"Table Main" is an available option in Vyatta 5400 policy-based routing. The equivalent in VRA is "routing-instance default".







 Policy based routing on the tunnel interface 



 Policy based routing on the tunnel interface issues 

On the IBM Cloud® Virtual Router Appliance PBR (Policy-Based Routing), policies can be applied to data plane interfaces for inbound traffic, but not to loopback, tunnel, bridge, OpenVPN, VTI, and IP unnumbered interfaces.





 Policy based routing on the tunnel interface workarounds 

There are currently no workarounds for this issue.







 OpenVPN 



 OpenVPN issues 

OpenVPN does not start working when using the push-route parameter on the IBM Cloud® Virtual Router Appliance.





 OpenVPN workarounds 

Use the openvpn-option parameter instead of push-route.







 GRE/VTI over IPSEC + OSPF 



 GRE/VTI over IPSEC + OSPF issues 



* When VIF has multiple subnets configured, traffic cannot go across those subnets in the VRA.
* InterVlan routing is not working on the VRA.







 GRE/VTI over IPSEC + OSPF workarounds 

Use implicit allow rules to accept traffic across VIF interfaces.







 IPsec 



 IPsec issues 

IPsec (prefix-based) does not work with IN Filter.





 IPsec workarounds 

Use IPsec (VTI BASED).







 IPSEC "match-none" 



 IPSEC "match-none" issues 

With Vyatta 5400 devices, the following firewall rule is allowed:

set firewall name allow rule 10 ipsec

However, with IBM Cloud® Virtual Router Appliance, there is no IPsec.





 IPSEC "match-none" workarounds 

Possible alternative rules for VRA devices:

match-ipsec Inbound IPsec packets
match-none Inbound non-IPsec packets







 IPSEC 'match-ipsec" 



 IPSEC 'match-ipsec" issues
Before setting a VLAN to "route through" on a gateway appliance, please make sure that the VLAN and subnet gateways of the subnets assigned to the VLAN are configured properly on the gateway appliance itself. You should also make sure to allow proper traffic flow using firewall rules or security policies. If you do not configure the VLAN(s), subnet gateway(s), and firewall rules or security policies properly before setting the VLAN to "route through", the traffic will be routed to your gateway appliance and may cause outages to your servers or services on that VLAN. For Juniper vSRX, refer to [Creating the new interface, zone, and address book subnet](https://cloud.ibm.com/docs/vsrx?topic=vsrx-creating-the-new-interface-zone-and-address-book-subnet), and for Vyatta Virtual Router Appliance refer to complete [Configuring your VLANs](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-routing-your-vlans).



 Associating a VLAN to a gateway appliance 

VLAN association is the administrative linking of an eligible VLAN to a gateway appliance so that it can be set to "route through". You must associate a VLAN to a gateway appliance before it can be set to "route through", and this process does not automatically set it to "route through". The VLAN continues to be managed by the Front-end Customer Routers (FCRs) or Back-end Customer Routers (BCRs) until it is set to "route through" on the gateway appliance details page.

VLANs can be associated to only one gateway appliance at a time and must not already have a [hardware firewall](https://cloud.ibm.com/docs/hardware-firewall-shared?topic=hardware-firewall-shared-about-hardware-firewall-shared-) applied. If there is, all servers on that VLAN will have their traffic routed to the hardware firewall.
Hardware Firewall docs 

A Hardware Firewall is a network device that is connected upstream from a server. The firewall blocks unwanted traffic from a server before the traffic ever reaches the server. The main advantage to having a Hardware Firewall is that a server only has to handle 'good' traffic and no resources are wasted dealing with the 'bad' traffic.

 Recommended content 

[Getting started with Hardware Firewall The Hardware Firewall provides customers with an essential layer of security that is provisioned on demand without service interruptions. It prevents unwanted traffic from hitting your servers, reducing your attack surface, and allowing your server resources to be dedicated for their intended use.](https://cloud.ibm.com/docs/hardware-firewall-shared?topic=hardware-firewall-shared-getting-started)[Configuring the Hardware Firewall Configuring your Hardware Firewall is as simple as creating a set of rules to allow access to certain IP addresses/ports from specific internet addresses while denying traffic from other sources.](https://cloud.ibm.com/docs/hardware-firewall-shared?topic=hardware-firewall-shared-configuring-the-hardware-firewall-shared-)[Viewing your various firewalls You can identify the Hardware Firewalls in use on an account and their associated VLANs, as well as identify unprotected VLANs and plan the deployment of a firewall solution.](https://cloud.ibm.com/docs/hardware-firewall-shared?topic=hardware-firewall-shared-viewing-your-various-firewalls)

 Learn more 

[IBM Developer<br><br>Visit IBM Developer for technical articles, code patterns, tutorials, and more.<br><br>![112-Developer-tools.svg](https://cloud.ibm.com/media/docs/images/homepage/112-Developer-tools.svg)](https://developer.ibm.com/depmodels/cloud/)[Architecture Center<br><br>Discover the architecture references available for this product.<br><br>!
* ibmcloud is security-group-rule-add my-sg inbound all --remote my-sg
* ibmcloud is security-group-rule-add 72b27b5c-f4b0-48bb-b954-5becc7c1dcb3 inbound tcp --port-min 4 --port-max 22 --output JSON







 Command options 



* GROUP: ID or name of the security group.
* DIRECTION: Direction of traffic to enforce. One of: inbound, outbound.
* PROTOCOL: Protocol to enforce. One of: all, icmp, tcp, udp.
* --vpc: ID or name of the VPC. It is only required to specify the unique resource by name inside this VPC.
* --remote: The set of network interfaces from which this rule allows traffic. It can be specified as either a REMOTE_ADDRESS, CIDR_BLOCK, or SECURITY_GROUP. If unspecified, then traffic is allowed from any source (or to any source, for outbound rules).
* --icmp-type: ICMP traffic type to allow. Valid values from 0 to 254. This option is specified only when protocol is set to icmp. If unspecified, all types are allowed.
* --icmp-code: ICMP traffic code to allow. Valid values from 0 to 255. This option is specified only when protocol is set to icmp. If unspecified, all codes are allowed.
* --port-min: Minimum port number. Valid values are from 1 to 65535. This option is specified only when protocol is set to tcp or udp. If unspecified, all ports are allowed (default: 1).
* --port-max: Maximum port number. Valid values are from 1 to 65535. This option is specified only when protocol is set to tcp or udp. If unspecified, all ports are allowed (default: 65535).
* --output: Specify output format, only JSON is supported. One of: JSON.
Click Save when complete.



The new NAT rule will be created. This may take a few seconds to complete. Repeat the process for other destination NAT rules, if needed in your solution.

To create a source NAT (SNAT) rule:



1. In the top menu navigation, click on Networking.
2. Click on Edge Gateways and select your virtual data center's Edge Gateway.
3. In the left navigation under Services, click on NAT.
4. Click on New to create a new NAT rule.
5. The Add NAT Rule wizard will appear. There are four fields that must be filled out.



1. Name – In this example, snat-to-inet is used.
2. Interface type – Select SNAT (source NAT) as the interface type.
3. External IP – Input one of the public IP addresses provided by IBM Cloud to your instance. You may click on the information button to the right of the field to see these IP addresses. In this example, public-ip-1 (the second actual public IP obtained in the previous step) is used.
4. Internal IP – This is the CIDR range of the network you created in the previous step. In this example, 192.168.100.0/24 is used.
5. Application - Leave empty.



6. Click Save when complete.



The new NAT rule will be created. This may take a few seconds to complete. Repeat the process for other source NAT rules, if needed in your solution.





 Step 5: Create firewall rules 

The next step is to create firewall rules. By default, the IBM Cloud® for VMware as a Service – single tenant instance has been provisioned with a default firewall rule that will drop all traffic for ensuring basic network security. Additional rules must be put in place to allow the traffic from the previously created network to access the Public Internet and for you to access the virtual machine from the Public Internet.



Firewall rules

 Name Applications Source Destination Action IP protocol 

 dnat-to-jump RDP, ICMP ALL Any ipset-dnat-to-jump Allow IPv4
}
"snat-to-internet-1" = {
"dnat_external_port" = ""
"external_address" = "xxx.yyy.zzz.18"
"internal_address" = "172.26.1.0/24"
"name" = "demo-snat-to-internet-1"
"rule_type" = "SNAT"
"snat_destination_address" = ""
}
"snat-to-internet-2" = {
"dnat_external_port" = ""
"external_address" = "xxx.yyy.zzz.18"
"internal_address" = "172.26.2.0/24"
"name" = "demo-snat-to-internet-2"
"rule_type" = "SNAT"
"snat_destination_address" = ""
}
}
Show more

You can get the configured firewall rules though an output created_fw_rules, IP Sets with created_ip_sets and Static Groups with created_static_groupsand so on. For example:

terraform output created_fw_rules



After provisioning, please make sure you adjust the example firewall rules according to your standards and needs. They will expose public access to your virtual machines, like ssh and RDP, which is configured here for demonstration purposes only.





 Step 5: Connect to the VMware Cloud Director Console 

Refer to the [alternative tutorial](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vmware-as-a-service-vdc) how to use and access VMware Cloud Director Console. Check the deployed assets and how the Edge Gateway has been configured (FW and NAT rules).

Get the virtual machines' usernames and passwords from the terraform output, for example:

terraform output created_virtual_machines

To connect to the virtual machine with console in VMware Cloud Director Console:



1. Click on Launch Web Console to open a local console to the virtual machine.
For Entrust KeyControl 4.3.2 and later, IBM Cloud for VMware Solutions provides automatic renewal support for Entrust licenses with the Call Home feature enabled. For VMware vCenter Server® instances that are not private-only, Entrust KeyControl is deployed with firewall and SNAT (Source Network Address Translation) rules that are defined on the management services ESG mgmt-nsx-edge.

These rules enable internet access for the Entrust VMs. If internet access is not enabled, the license that is applied to your Entrust KeyControl installation will expire after a year.

For private-only vCenter Server environments, the VMware® NSX Edge Services Gateway (ESG)mgmt-nsx-edge is not added. Therefore, the firewall and SNAT rules are not defined. As a result, internet connectivity cannot be enabled for private-only instances and Entrust licenses expire annually.



 Procedure to find the firewall and SNAT rules defined 



1. Log in to the VMware vSphere® Web Client (FLEX) and find the ESG mgmt-nsx-edge.
2. Click Home > Networking & Security > NSX Edges.
3. Double-click the ESG mgmt-nsx-edge and click the Manage tab.
4. Go to the Firewall tab and find the Entrust rules. Note the source IP addresses, which are the IP addresses for the Entrust VMs.
5. Go to the NAT tab and find the SNAT rules that are created for the Entrust VMs. The source IP addresses match the IP addresses that you noted in the previous step.







 Procedure to enable internet connectivity for Entrust KeyControl 



1. Complete steps 1 - 3 in the previous procedure.
2. Click Settings and then Interfaces. Note the IP address for the private uplink. This address is the new default gateway.
3. Click Home > Hosts and Clusters and find the Entrust VMs. Right-click one of the VMs and click Open Console.
4.
Review the following notes for configuring DHCP on the edge gateway.



* The IP Range is a range from the Organization virtual data center network that is attached to the edge.
* You can define the names for the Primary Name Server and the Secondary Name Server now or update the names later.
* The Default Gateway is the gateway CIDR or the Organization virtual data center network that is attached to the edge.
* Ensure to set the DHCP service status to enabled.







 Connect the VMs to the network 

Stand-alone VMs, or VMs in a vApp, can connect to an Organization virtual data center network.

From the tenant portal, access the hardware properties of the VMs and add the new network interface to the NICs field. Repeat the procedure for extra VMs. For more information, see [Change the hardware properties of a virtual machine](https://docs.vmware.com/en/VMware-Cloud-Director/10.1/VMware-Cloud-Director-Tenant-Portal-Guide/GUID-BB95EAB5-13D7-4C4A-BDA3-AA1338BC01CA.html?hWord=N4IghgNiBcIHIEkDCBnEBfIA).

After the VMs are connected to the Organization virtual data center network, they are able to communicate with each other. You can ping from one of the VMs to another to test. If the ping command does not respond, check the OS firewalls to see whether ICMP is allowed.





 Enable inbound and outbound traffic 

To enable VMs on the Organization virtual data center network to reach an external network, configure a SNAT (Source Network Address Translation) rule and a firewall policy to allow the VM traffic outbound. To allow inbound traffic from an external network, you must configure a DNAT (Destination Network Address Translation) rule and a firewall policy.

Before you create the firewall and NAT rules, capture the information that is necessary for subsequent steps.



1. From the tenant portal, click Data Centers.
2. On the main page, under Virtual Data Center, click the virtual data center for that edge gateway.
3.