vania-janet/multiturn-rag-retrieval-data huggingface dataset:
AT&T NetBond for Cloud ordering considerations 

Follow these steps to request a VLAN assignment from AT&T NetBond for Cloud:



1.  Order the NetBond connect on the AT&T portal.

NetBond is responsible for making sure that this VLAN is not in use with any NetBond connections within IBM.
2.  Using your IBM Cloud account, order an IBM Cloud® Direct Link Connect gateway by using the [IBM Cloud console](https://cloud.ibm.com/login). For instructions, see [Ordering IBM Cloud Direct Link Connect](https://cloud.ibm.com/docs/dl?topic=dl-how-to-order-ibm-cloud-dl-connect).



*  When defining the IP range to be used for BGP, select Manual-select IP.
*  Choose the IP range that you want to use with this gateway.

Ensure that the range you choose is the range that you specified in the NetBond portal.
*  In the BGP ASN field, specify the ASN provided by AT&T.



3.  Open an IBM Support case. For details, see [Create a case](https://cloud.ibm.com/unifiedsupport/cases/add) in the IBM Support Center.



*  Select the Direct Link Connect tile.
*  In the IBM Support case, add the following information:



*  Subject: DL Connect manual implementation AT&T NetBond
*  Description:



*  Route this ticket directly to the Special Network Services (SNS) queue for Direct Link Connect implementation with AT&T NetBond.
*  Include the NetBond connection service key that was assigned by NetBond (as provided in Step 1).
*  Include the direct link name or service key from the Direct Link page. For example, 0xx43ex3-b8f0-4d52-8b84-x91af2x02yy3.









The SNS team receives the IBM Support case and initiates a series of steps to bring routers and the IBM portal database into synchronization.

After completion, the IBM Support case is annotated and closed. The timeframe for this activity is five business days from receipt of the case in the SNS queue.
For more information, see the [Red Hat OpenShift re-encrypt route documentation](https://docs.openshift.com/container-platform/4.11/networking/routes/secured-routes.htmlnw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes). 



If you don't need to use a custom domain, you can use an IBM-provided route hostname in the format <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud.





 Ingress controller health checks 

Allow access through network policies or other firewall rules so that your Ingress controller services are reachable by the Ingress controller health check.

Classic: If you use Calico pre-DNAT network policies or another custom firewall to block incoming traffic to your cluster, you must allow inbound access on port 80 from the Red Hat OpenShift control plane and Akamai's IPv4 IP addresses to the IP addresses of your Ingress controller services so that the Red Hat OpenShift control plane can check the health of your Ingress controllers. For example, if you use Calico policies, [create a Calico pre-DNAT policy](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesisolate_workers) to allow inbound access to your Ingress controllers from [Akamai's source IP addresses](https://github.com/IBM-Cloud/kube-samples/tree/master/akamai/gtm-liveness-test) that are used to check the health of your Ingress controllers on port 80 and the [control plane subnets for the region where your cluster is located](https://github.com/IBM-Cloud/kube-samples/tree/master/control-plane-ips). Continue to the next step to get the Ingress controller service IP addresses.
[Genesys create trunk](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/phone-genesys-create-trunk.png)
5. Under Outbound, scroll to the SIP Servers or Proxies section. Specify the following information:



* In the Hostname or IP Address field, type the SIP URI (not including sips:) from your Watson Assistant phone integration settings.
* In the Port field, type 5060.



Click the + button.

Currently, SIPS and digest authentication are supported.
6. Under SIP Access Control, add the [IP addresses](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-deploy-phone-configdeploy-phone-config-byost) for the data center where your assistant is located.
7. Under Identity, specify the following information:



* Toggle the Address Omit + Prefix switch to Disabled.

![Disable address omit + prefix](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/phone-genesys-address-omit-disabled.png)



8. Under Media, remove Opus from the Preferred Codec List. Click Select a Codec and then select g729 to add it to the list. Leave PCMU as the first item in the list.

![Genesys select codec](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/phone-genesys-select-codec.png)
9. Under Protocol, enable Take Back and Transfer.
10. Click Save External Trunk.
Integrating with a Key management service 

You can encrypt the data that you store in IBM Cloud databases by using encryption keys that you can control. Manage the lifecycle of your encryption keys that are used for your IBM Cloud resources, services and applications.

You can use either one of the following options:



* Bring Your Own Key (BYOK) through IBM Key Protect, and use one of your own keys to encrypt your databases and backups.
* Hyper Protect Crypto Services (HPCS) - IBM Cloud® Hyper Protect Crypto Services, a dedicated key management service, and Hardware Security Module (HSM) that provides you with the Keep Your Own Key capability for cloud data encryption with exclusive control of your encryption keys.



BYOK and KYOK capabilities are supported only for App Configuration Enterprise plan.

For more information, see [Managing encryption](https://cloud.ibm.com/docs/app-configuration?topic=app-configuration-ac-managing-encryption).

If you are using App Configuration CLI or API to create integration with a key management service (KMS), ensure that you have enabled authorization to grant access between services before integrating with a KMS service. For more information, see [Using authorizations to grant access between services](https://cloud.ibm.com/docs/app-configuration?topic=app-configuration-ac-int-key-managementac-using-auth-access-between-services).

You can create and bring keys that are created by using Key Protect or Hyper Protect Crypto Services. To get started, you need [Key Protect](https://cloud.ibm.com/catalog/key-protect) or [Hyper Protect Crypto Services](https://cloud.ibm.com/catalog/services/hyper-protect-crypto-services) provisioned on your IBM Cloud account. For more information, see [provisioning a key protect instance](https://cloud.ibm.com/docs/key-protect?topic=key-protect-provision) or see [provisioning a Hyper Protect Crypto Services instance](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started).
* You can choose to use the integration capabilities with IBM Cloud® Key Management Services like IBM® Key Protect and Hyper Protect Crypto Services.

You can use IBM® Key Protect to provision encrypted keys for apps across IBM Cloud services. As you manage the lifecycle of your keys, you can benefit from knowing that your keys are secured by FIPS 140-2 Level 3 certified cloud-based hardware security modules (HSMs) that protect against the theft of information. When you integrate COS with the Key Protect service, you can add envelope encryption to your DEKs. In Key Protect, you can provision highly secure root keys, which serve as primary keys that you control in the service. When you create a bucket, you can configure envelope encryption for the bucket at its creation. This added protection wraps (or encrypts) the DEKs associated with the bucket by using a root key that you manage in Key Protect. The practice, called key wrapping, uses multiple AES algorithms to protect the privacy and the integrity of your DEKs, so only you control access to their associated data.

Hyper Protect Crypto Services is a single-tenant, dedicated HSM that is controlled by you. The service is built on FIPS 140-2 Level 4-certified hardware, the highest offered by any cloud provider in the industry.



If you need to use your own key to encrypt the data at-rest in a bucket, use the following table to help you identify the features that you should consider when you create a bucket:



Table 8. Use your own encryption key

 Requirement Storage class: Standard Storage class: Vault Storage class: Cold Vault Storage class: Flex 

 Type of workload Continuous access Data isn't accessed frequently Accessed every 90 days or less Dynamic workloads where access patterns are difficult to predict 
 Data resiliency Regional Regional Regional Regional 
 Retention policy [15] NO NO NO NO 
 Expiration policy ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/log-analysis/images/checkmark-icon.svg) !
This means when you order Direct Link Connect via the IBM Portal, you need to populate the Layer 3 providers ASN for the BGP session, not your customer ASN



* Layer-3 IP VPN or AVPN networks enable "any-to-any" connectivity.
* Layer-3 networks require the network service provider to maintain a BGP session between the enterprise and IBM Cloud.
* Certain network service providers might restrict certain functionalities across their network when using Layer-3 connections, such as ASN prepend, GRE tunneling, and so forth. Be sure to check with your provider about possible restrictions.







 Partner interconnection table 

The following table summarizes the type of connections that each IBM Cloud partner provides.



Table 1. Partner interconnection table

 Partners Interconnection type 

 AT&T NetBond for Cloud Layer 3 
 AT&T Cloud Gateway (formerly known as RedFringe) Layer 3 
 Bell Canada Layer 3 
 British Telecom Layer 3 
 CenturyLink IP VPN Layer 3 
 CenturyLink Dynamic Connections Layer 2 
 Chief Telecomm Layer 2 
 China Unicom Layer 3 
 Colt Layer 2 
 Console Connect Layer 2 
 Epsilon Layer 2 
 EU Networks Layer 2 
 IBM BlueFringe Layer 3 
 Intercloud Layer 3 
 IXReach Layer 2 
 Megaport Layer 2 
 Neutrona Layer 2 
 nextGen GNPP Layer 3 
 NTT Layer 3 
 Orange Business Services Layer 3 
 PacketFabric Layer 2 
 Softbank Layer 3 
 SES Networks Layer 2 
 Tata IZO™ Private Connect Layer 3 
 Arelion Layer 3 
 Telstra Layer 3 
 Tokai Layer 2 
 Verizon SCI Layer 3 
 Vodafone Layer 3 
 Zayo Cloud Link Layer 2
After you create the route, run oc edit route <app_service_name> and change the route's targetPort value to https. You can test the route by running curl -I --http2 https://<route> --insecure.
* Edge: If you use a custom domain, include --hostname, --cert, and --key options, and optionally the --ca-cert option. For more information about the TLS certificate requirements, see the [Red Hat OpenShift edge route documentation](https://docs.openshift.com/container-platform/4.11/networking/routes/secured-routes.htmlnw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes).

oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
* Re-encrypt: If you use a custom domain, include --hostname, --cert, and --key options, and optionally the --ca-cert option. For more information about the TLS certificate requirements, see the [Red Hat OpenShift re-encrypt route documentation](https://docs.openshift.com/container-platform/4.11/networking/routes/secured-routes.htmlnw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes).

oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]



4. Verify that the route for your app service is created.

oc get routes
5.
For more information, see [bare metal VLAN trunks](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-optionsbare-metal-vlan-trunks).



 Creating VLAN trunks using the UI 

Create a VLAN trunk using the console by taking the following steps:



1. From your browser, open the [IBM Cloud console](https://cloud.ibm.com/) and log in to your account.
2. From the console, click the Menu icon ![menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) and select Classic Infrastructure.
3. Select Network > IP Management > VLANs.
4. Select a VLAN by clicking on its fully qualified name in the list of VLANs.
5. Click Attach trunk in the Devices with trunks section.
6. Select a resource from the devices list in the panel that appears.
7. Click Attach to establish the trunk, or click Cancel to close the panel without adding the trunk.



Add VLANs as trunks to a network component. The VLANs given must be assigned to your account, and on the router to which this network component is connected. The native VLAN (networkVlanId/networkVlan) of the selected device cannot be added as a trunk.

You must manually configure your host's network with your added VLAN trunks before they can be used to pass traffic.





 Removing VLAN trunks using the UI 

Remove a VLAN trunk using the console by taking the following steps:



1. From your browser, open the [IBM Cloud console](https://cloud.ibm.com/) and log in to your account.
2. From the console, click the Menu icon ![menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) and select Classic Infrastructure.
3. Select Network > IP Management > VLANs.
4.
Specify a name for the project and verify your account information.
2. On the welcome page, select Flex as the Twilio product for your new project. Fill out the questionnaire and then click Get Started with Twilio.

After your Flex project has been provisioned, return to the [Twilio console](https://www.twilio.com/console). Make sure you have selected the correct project from the drop-down list.
3. In the navigation menu, click the All Products & Services icon.
4. Click Twilio Programmable Voice > Settings > General.
5. Under Enhanced Programmable SIP Features, toggle the switch to Enabled.







 Creating the call flow 

After you have your phone integration and Twilio Flex project configured, you must create a call flow with Twilio Studio and provision (or port) the phone number you want your assistant to work with.

To create the call flow:



1. In the navigation menu, click the All Products & Services icon.
2. Click Studio.
3. Click + to create a new flow.
4. Name the new flow and then click Next.
5. Select Start From Scratch and then click Next.
6. At this point you should have a Trigger widget at the top of your flow canvas.
7. Click the Trigger widget.
8. Make note of the value from the WEBHOOK URL field. You will need this value in a subsequent step.







 Configuring the phone number 



1. In the navigation menu, click the All Products & Services icon.
2. Click Phone Numbers.
3. Under Manage Numbers, configure the phone number you want your assistant to use. Select Buy a Number to buy a new number, or Port & Host to port an existing phone number.
4. In the Active Numbers list, click the new phone number.
5. Under Voice and Fax, configure the following settings:
In this case, the SG Client will use this certificate/key pair for its outbound connection to the defined resource, the On-prem resource needs to add this certificate to its CA to communicate with the SG Client.

For a cloud destination, it will appear under [User Authentication](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-add-destdest-user-auth) if a TLS protocol has been selected. In this case, the SG Client will use this certificate/key pair to create TLS listeners, the On-prem app needs to add this certificate to its CA to communicate with the SG Client.







 Configuring Network Security 

To prevent all but specific IP addresses from connecting to your cloud hosts and ports, you can choose to enforce iptables rules on your on-premises destination. ![Network Security Panel](https://cloud.ibm.com/docs-content/v1/content/690bf9a59650e0582967be8899e39840589532f7/SecureGateway/images/networkSecurity.png?raw=true)

To enforce iptables rules, check the box Restrict cloud access to this destination with iptables rules from the Network Security panel. Once the box is checked, you can begin adding the IPs that should be allowed to connect. If no IPs are provided, all connections to this cloud hosts and ports will be rejected as long as the Restrict cloud access box is checked.

Note: The IPs or ports provided must be the external IP address that the Secure Gateway servers will see, not the local IP address of the machine making the request.



 Adding iptables rules 

When adding rules to iptables, you can provide individual IPs or an IP range along with either a single port or a port range. All ranges provided are inclusive. The following table has some examples as well as how they will resolve within iptables:



 IP Addresses Ports Results 

 1.2.3.4 5000 Only IP 1.2.3.4 from port 5000 will be allowed.
You are responsible for meeting certain [TLS requirements](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-encryption-in-transitvpc-architecture-encryption-in-transit-tls-requirements) along with [acceptable cipher suites](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-encryption-in-transitvpc-architecture-encryption-in-transit-tls-cipher-suites).

Next, configure the management UI to allow the acceptable cipher suites of TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 only. You can do this configuration only with the command line interface.



1. Log on with SSH port 22 to the management IP address of the BIG-IP.
2. Issue the following commands:

tmsh modify /sys httpd ssl-ciphersuite 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256'
tmsh save /sys config
tmsh list /sys httpd ssl-ciphersuite
3. Logout of the command line interface.







 Step 4: Replacing the configuration utility's self-signed device certificate 

By default, the configuration utility is deployed with a self-signed certificate. You must replace the certificate according to the [TLS requirements](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-encryption-in-transitvpc-architecture-encryption-in-transit-tls-requirements). For more information on replacing the BIG-IP self-signed certificate, see [Replacing the Configuration utility's self-signed device certificate with a CA-signed device certificate](https://support.f5.com/csp/article/K42531434).
Creating a Connector 

A Connector provides a secure connection between a specific remote location and IBM Cloud. Use the Satellite console to create your Connector.



1.  From the [Satellite console](https://cloud.ibm.com/satellite/locations), click Connectors.
2.  Click Create connector.
3.  For Name, enter a unique name for your Connector. The default value is connector.
4.  For Tags, enter one or more tags that can help you organize resources throughout your account by filtering by tags from your resource list. This field is optional. For more information, see [Working with tags](https://cloud.ibm.com/docs/account?topic=account-tag).
5.  For Resource group, assign a resource group to your connector. The default value is Default.
6.  For Description, describe what this Connector is used for. This field is optional.
7.  For the Managed from menu, select the IBM Cloud region that is closest to where your infrastructure resides to ensure low network latency.
8.  In the Summary panel, review your order details, and then click Create connector.





  Next steps 

After creating a Connector, you must set up an agent to complete your set up.



*  Set up a Connector agent. For more information, see [Running a Connector agent](https://cloud.ibm.com/docs/satellite?topic=satellite-run-agent-locally).
*  [Run the agent image in Swarm mode](https://cloud.ibm.com/docs/satellite?topic=satellite-run-agent-swarm) for high-availability.
*  [Follow the end-to-end example](https://cloud.ibm.com/docs/satellite?topic=satellite-end-to-end) to run the agent, configure your endpoints, and add TLS support.
* UI
* CLI
* API
* Terraform







 Adding connections to a VPN gateway 

You can add connections when you create an IBM Cloud VPN for VPC, or after you provision a VPN gateway. When you configure a VPN connection, you can choose to connect with auto-negotiation or use a pre-defined custom IKE or IPsec policy. For more information, see [About policy negotiation](https://cloud.ibm.com/docs/vpc?topic=vpc-using-vpnpolicy-negotiation).

The IKE Phase 1 and Phase 2 (IPsec) security options that you specify for the connection must be the same options that are set on the peer gateway for the network outside your VPC.



 Adding a connection in the UI 

To add a VPN connection to an existing VPN gateway, follow these steps:



1. Highlight the row of the gateway in the VPN gateways table, then click New connection from the Actions menu ![Actions menu](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/overflow.png).

Alternatively, on the gateway's details page, you can click Create + in the VPN connections section.
2. Define a connection between this gateway and a network outside your VPC by specifying the following information:



* VPN connection name - Enter a name for the connection, such as my-connection.
* Peer gateway address - Specify the IP address of the VPN gateway for the network outside your VPC.
* Preshared key - Specify the authentication key of the VPN gateway for the network outside your VPC. The preshared key is a string of hexadecimal digits, or a passphrase of printable ASCII characters. To be compatible with most peer gateway types, this string must follow these rules:



* Can be a combination of digits, lower or upper case characters, or the following special characters: - + & ! @ $ % ^ * ( ) . , :
To allow SSL services support to encrypt traffic to your upstream apps that require HTTPS, use the Kubernetes Ingress resource [backend protocol annotation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/backend-protocol) and the [backend certificate authentication annotations](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/backend-certificate-authentication).

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
nginx.ingress.kubernetes.io/proxy-ssl-secret: app1-ssl-secret
nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: 5
nginx.ingress.kubernetes.io/proxy-ssl-name: proxy-ssl-name=mydomain.com
nginx.ingress.kubernetes.io/proxy-ssl-verify: true





 Accessing apps with non-standard TCP ports 

To access an app via a non-standard TCP port, follow these steps.



1. Create a tcp-services ConfigMap to specify your TCP port, such as the following example ports. For the requirements of the tcp-services ConfigMap, see [this blog](https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/).

apiVersion: v1
kind: ConfigMap
metadata:
name: tcp-services
namespace: kube-system
data:
9000: "<namespace>/<service>:8080"
2. Create the ConfigMap in the kube-system namespace.

kubectl apply -f tcp-services.yaml -n kube-system
3.