IBM Cloud private connectivity offerings

This white paper explores how to establish a private connection to IBM Cloud by using various network topologies.

Introduction

These network topologies enable secure, high-performance connectivity between on-premises infrastructure and IBM Cloud resources. The following options are available:

Direct Link Dedicated - Single tenant connection to IBM Cloud Point of PresencesA physical location that stores servers and routers in a network cloud. (PoPs)
Direct Link Connect - Multi-tenant service provider connection to IBM Cloud PoPs
VPN (site-to-site) - VPN tunnel from on-premises firewall to IBM Cloud VPN
VPN (client-to-site) - VPN tunnel from laptop to IBM Cloud VPN
Satellite Connector - A layer-7, endpoint-oriented connection from IBM Cloud to access on-premises data source.

Private connectivity resources within IBM Cloud can be achieved with Transit Gateway (private backbone).

IBM Cloud Overview — IBM Cloud Private Connectivity Overview

Required skills for system administrators

Creating network connectivity in IBM Cloud is a critical task for network administrators. It allows you to connect your on-premises networks to the cloud, as well as connect different resources within the cloud itself. However, creating network connectivity can be a complex task, and it requires a number of different skills.

Administrators who need to create network connectivity in IBM Cloud should have a strong understanding of the following topics:

IP addressing and routing
Cloud networking concepts
IBM IBM Cloud networking services

Administrators should also be familiar with the following tools and technologies:

The IBM Cloud console
The IBM Cloud CLI
The IBM Cloud SDKs
Network monitoring and debugging tools

IBM Cloud offering descriptions and key differentiators

IBM Cloud offers the following private connectivity services.

Direct Link Dedicated

The IBM Cloud Direct Link solution seamlessly connects your on-premises resources to your cloud resources, through a single-tenant, fiber-based, cross-connect terminated connection. This offering is also used by colocation facilities that are next to IBM Cloud PoPs and data centers.

Private access to IBM Cloud using dedicated infrastructure.
High cost for dedicated connectivity with increased bandwidth options.
Single-tenant solution for maximum throughput.
Optimal for large or frequent data transfers.

Learn more

Direct Link Connect

Direct Link Connect uses a service provider to quickly establish and deliver connectivity to IBM Cloud locations. These service providers are already connected to the IBM Cloud network, and use multi-tenant, high capacity links (also known as network-to-network interfaces, or NNI).

Private access to IBM Cloud using shared infrastructure.
Moderate cost, private and secure, shared infrastructure, and fast deployment.
Ideal for multicloud environments with your server provider’s network.
Virtual connectivity for rapid provisioning.

Learn more

Transit Gateway

Use IBM Cloud Transit Gateway to interconnect IBM Cloud resources and Virtual Private Cloud (VPC) infrastructures worldwide, keeping traffic within the IBM Cloud network.

Deliver your applications around the world, with global routing across the IBM Cloud network.
Simplify your network and build applications — without managing a distributed network.
Scale and share IBM Cloud services  like IBM classic infrastructure resources and IBM VPCs.
Keep traffic within the IBM Cloud network without traversing the public internet.

Learn more

VPN (site-to-site gateways)

You can use the IBM Cloud VPN for VPC service to securely connect your Virtual Private Cloud (VPC) to another private network. Use a static, route-based VPN, or a policy-based VPN to set up an IPsec site-to-site tunnel between your VPC and your on-premises private network or another VPC.

Protocol suite that provides secure communication between devices.
Low-cost, pay-as-you-go pricing
Configurable mechanism to detect the availability of an IPsec peer.
Internet Key Exchange (IKE) is a part of the IPsec protocol that is used to establish VPN connections.
Perfect Forward Secrecy (PFS) ensures that DH-generated keys aren't used again during IPsec renegotiation.
Supports a pre-shared key for Phase 1 peer authentication. Supported authentication algorithms for both phases include SHA-256, SHA-384, and SHA-512.

Learn more

VPN (client-to-site servers)

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

Multi-factor client authentication.
Provides added layers of security with integrated authentication methods.
Low cost, pay-as-you-go pricing.
Availability in all MZRs' worldwide.
Supports both stand-alone (pilot) and high availability (production) deployments.
High availability spanning across zones, providing better performance and resiliency.
TLS 1.2 / 1.3-based secure or encrypted connectivity over the internet.

Learn more

Satellite Connector

Satellite Connector provides a lightweight solution for IBM Cloud services to reach out to on-premises data sources. If bidirectional communication is needed, or Cloud services to be deployed on the client on-premises, refer to a Satellite Location.

Provides client-owned L7 endpoints for IBM Cloud services to access data on the client premise, rather than bridging on-premises networks with cloud like a VPN.
Allows you to use your AWS, Azure, Google Cloud infrastructure, your on-premises hardware, or purchase from IBM/IBM partners.
Uses internet or Direct Link for transport.
Operated as-a-service by IBM.
Use a single dashboard to centralize observability and management across all locations.
Extend access policies, logging, monitoring, and other controls to all locations.
Low cost, pay-as-you-go pricing without bandwidth capacity limitations.

If bidirectional communication is needed or the ability to deploy IBM Cloud services on your on-premises or other cloud infrastructures are required, a Satellite Location provides more capabilities. For more information, see Understanding Satellite location and hosts.

Learn more

Offering comparisons

Pricing

There are many factors to consider regarding pricing, such as peer configurations, dependent offerings, local providers. For example, a VPN site-to-site gateway or a VPN client-to-site server does not charge for an extra floating IP, and the pricing is also location-based.

To calculate pricing for IBM Cloud offerings, use the IBM Cloud cost estimator.

Pricing comparison
IBM Cloud service	High cost	Medium cost	Low cost
Direct Link Dedicated
Direct Link Connect
Transit Gateway
VPN (site-to-site)
VPN (client-to-site)
Satellite Connector

Connectivity

Direct Link Dedicated: Connect VPC networks directly with physical connections.
Direct Link Connect: Connect VPC networks through intermediate partner networks.
Transit Gateway: Connect resources deployed in your VPC virtual networks with an Availability Zone (AZ) and between AZs.
VPN (site-to-site): Connect private networks with private connectivity over the internet.
VPN (client-to-site): Host a VPC network with private connectivity over the internet.
Satellite Connector: Connect with secure TLS 1.3 endpoint-oriented communications over the internet or Direct Link.

Latency and bandwidth

Direct Link offerings have the lowest latency followed by Satellite and VPN offerings. Latency is highly dependent on location.

Bandwidth:

Direct Link Dedicated: Speeds up to 10 Gbps.
Direct Link Connect: Speeds up to 5 Gbps.
Transit Gateway: Speeds up to or in excess of 10 Gbps.
VPN (site-to-site): Stand-alone mode up to 600 Mbps; High availability up to 1200 Mbps.
VPN (client-to-site): Speeds up to 650 Mbps.
Satellite Connector: Limited by client connectivity; maximum speed less than 1000 Mbps.

Provisioning time

Provisioning time includes completing names and configuration parameters, as well as other dependencies and prerequisites.

Direct Link Dedicated: 5-30 days
Direct Link Connect: 3-5 days, depending on your provider (Provisioning on the IBM side is the same day.)
Transit Gateway: 20-55 minutes
VPN (site-to-site gateways): 20 minutes to one hour
VPN (client-to-site servers): 20 minutes to one hour
Satellite Connector: 10 minutes

Security and data encryption

All solutions that are listed are private and secure. For more information, see Security and data encryptions in the Reference section for each service.

Resiliency

Solutions are diverse. To establish true redundancy, you must implement multiple connections to ensure that your solution meets your resiliency needs.

Monitoring and logging

Private connectivity options use various tools for monitoring and logging.

Monitoring and logging comparison
IBM Cloud service	Monitoring	Logging
Direct Link Dedicated	Route reports	Activity Tracker
Direct Link Connect	Route reports	Activity Tracker
Transit Gateway	IBM Cloud Monitoring	Activity Tracker
VPN (site-to-site)	IBM Cloud Monitoring	IBM Log Analysis
VPN (client-to-site)	IBM Cloud Monitoring	IBM Log Analysis
Satellite Connector	IBM Cloud Monitoring	Activity Tracker IBM Log Analysis

Deployment considerations

When planning your network architecture, it's important to consider the deployment factors to ensure optimal performance, reliability, and cost-effectiveness.

Direct Link Dedicated deployment considerations

Here are some deployment considerations to review when choosing Direct Link Dedicated.

Part 1: Direct Link Dedicated deployment considerations
Deployment consideration	Action
Set up a second, diverse direct link to prevent outages. Learn more
Review Direct Link Dedicated prerequisites.
Consider whether you want a metered or unmetered pricing plan. Metered has a lower port fee and charges a per GB usage free for egress traffic across the direct link. Unmetered billing has a higher port fee and no usage charges, which is ideal for customers who have higher egress traffic across their direct link.
Review Direct Link Dedicated planning considerations and planning for virtual connections.
Review Direct Link Dedicated known limitations.
Decide what type of network connection that you want to bind to your direct link. For example, you can create a direct, private connection between your on-premises network and IBM Cloud, or bind your direct link to transit gateways. Your on-premises network can then access IBM Cloud resources that are connected through the transit gateways. Learn more

Direct Link Connect deployment considerations

Here are some deployment considerations to review when choosing Direct Link Connect.

Part 1: Direct Link Connect deployment considerations
Deployment consideration	Action
Set up a second, diverse direct link to prevent outages? Learn more
Contact your service provider to determine the location to IBM Cloud by verifying your colocation or provider's capabilities to reach the Meet Me Room (MMR) and cross-connect into IBM Cloud. Also, make sure that you understand your provider's deployment process.
Review Direct Link Connect prerequisites.
Consider whether you want a metered or unmetered pricing plan. Metered has a lower port fee and charges a per GB usage fee for egress traffic across the direct link. Unmetered billing has a higher port fee and no usage charges, which is ideal for customers who have higher egress traffic across their direct link.
Review Direct Link Connect planning considerations and planning for virtual connections.
Review Direct Link Connect known limitations.
Decide whether you want to activate the optional BGP settings. See the following links for details. MD5 authentication bidirectional Forwarding Detection (BFD) Prepending an AS path to influence route priority Route filtering
Decide what type of network connection that you want to bind to your direct link. For example, you can create a direct, private connection between your on-premises network and IBM Cloud, or bind your direct link to transit gateways. Your on-premises network can then access IBM Cloud resources that are connected through the transit gateways. Learn more

Transit Gateway deployment considerations

Here are some deployment considerations to review when choosing Transit Gateway.

Part 1: Transit Gateway planning considerations
Deployment consideration	Action
Have you decided which Transit Gateway location to use?
Do you want to use local or global routing? Your choice depends on where the networks to be connected are located. Learn more
Have you addressed any overlapping routes in the connected networks? Overlapping routes are a common issue when configuring a transit gateway. If the routes from two or more connections overlap, traffic might not be routed as intended. Learn more
Are there routes that you don't want advertised over the transit gateway? Do you need to create prefix filters?
Have you considered what connection type you plan to use?
For a GRE tunnel or unbound GRE tunnel, have you configured redundant tunnels for high availability? There's no out-of-the-box redundancy with either GRE connection type. You must configure two GREs in different zones advertising the same routes to get redundancy. Learn more

Site-to-site VPN deployment considerations

Here are some deployment considerations to review when choosing a VPN for VPC.

Part 1: Site-to-site VPN deployment considerations
Deployment consideration	Action
Which IBM Cloud region do you plan to deploy the VPCs? The regions might be closest to your on-premises site.
What subnets in the VPC need to be connected through the VPN? Make sure that there's enough space in the subnet for the gateway.
Is there a requirement to separate connectivity between your VPN and your resources, such as the virtual server instances into VPCs?
How are your virtual server instances distributed in the VPC? VPN gateway is created in the zone that is associated with the subnet that you select and can be used to connect to virtual servers in the same zone. For zone fault tolerance, you can deploy one VPN gateway per zone.
Do you need your on-premises network to access service endpoints through your site-to-site connectivity option? Do you have resources in IBM Cloud on Classic that you need to access through VPN or another connectivity option?
Do you have a peer VPN gateway or router (or multiple gateways/routers) setup on-premises? If yes, what is the type or model of that gateway? If your peer gateway enforces Perfect Forward Secrecy (PFS), you need to set custom policies.
What will be the CIDRs on-premises? Note that local (VPC) and peer (on-premises) subnets of a VPN gateway connection should not overlap or conflict. / The local (VPC) subnet is specified when you create the VPN Gateway. For more information, see working with Working with subnets in VPC.
Is your VPN gateway on-premises behind a firewall doing Network Address Translation (NAT)?
Do you need the VPC resources to access the internet through VPN? Do you want any IP range to be blocked?

Performance and other things

Here are some site-to-site connectivity deployment considerations and actions.

Part 2. Site-to-site connectivity performance and other things
Deployment consideration	Action
What is the desired throughput of the site-to-site connectivity option (that is, Direct Link or VPN)? Is there a peak hour, month, or season? Site-to-site VPN supports up to 650 Mbps of throughput. Direct Link supports a much higher bandwidth up to 5 Gbps or 10 Gbps depending on your configurations.
What is your expected cost for the connectivity option? Site-to-site VPN uses a usage-based pricing that can be estimated by using the Cost Estimator. Direct Link has multiple pricing plans, varies by provider, and has higher cost. See [Direct Link Dedicated] (/docs/private-connectivity?topic=private-connectivity-reference-direct-link-dedicated) and Direct Link Connect for more information.

Client-to-site VPN deployment considerations

Here are some deployment considerations to review when choosing Client VPN for VPC.

Part 1. Client-to-site VPN deployment considerations
Deployment consideration	Action
Do you need your individual users to have private and secure access (client-to-site servers) to your VPC resources from anywhere (for example, the airport, a hotel, or from home)? If yes, where are these users located?
Do you need your individual users to access service endpoints through your client-to-site VPN? These endpoints securely connect to IBM Cloud services over the IBM Cloud private network.
Client-to-site VPN is integrated with Secrets Manager for server authentication. Are you familiar with Secrets Manager and do you have an existing public/imported/private certificate with your Secrets Manager instance?
Client-to-site VPN supports three types of client authentication: a client certificate, added security with a user ID and passcode, or both. Which will be your preferred way of authenticating your users?	Client certificate / User ID/passcode / Both
Do you use client-to-site VPN for critical workload that requires a multi-zone deployment, or a pilot where multi-zone deployment is not a must?
Do you need the VPN server to do SNAT making your VPN client IP invisible to the destination devices?

Performance and other things

Here are some client-to-site connectivity deployment considerations and actions.

Part 2. Client-to-site performance and other things
Deployment consideration	Action
If you need individual access to VPC (client-to-site connectivity) from remote, how many users can be connecting to VPC concurrently through VPN?
What is your expected cost for the connectivity option? Client-to-site VPN uses usage-based pricing that can be estimated by using the Cost Estimator. Direct Link has multiple pricing plans, varies by provider, and has higher cost. See Direct Link Dedicated and Direct Link Connect for more information.

Satellite Connector deployment considerations

Here are some deployment considerations to review when choosing a Satellite Connector.

Satellite Connector deployment considerations
Deployment consideration	Action
Do you need a lightweight, secure tunnel or gateway from IBM Cloud back to your on-premises environment? If this describes your use case, see Satellite Connector overview.
Still, not sure which solution fits your use case? See more detailed Satellite Location use cases or the Satellite Connector capability comparison with Secure Gateway.
Do you need to initiate communications from your on-premises to IBM Cloud? In this case, a Satellite Location is required instead of a Satellite Connector.
Do you need to route networks between your on-premises and IBM Cloud? If so, consider a VPN or Direct Link connection.
Do you also need to run IBM Cloud services like Red Hat OpenShift on your own infrastructure, another cloud provider infrastructure, or on the edge? If this describes your use case, see Understanding Satellite locations and hosts.

Use cases

Explore typical scenarios where the connectivity method is most effective.

Direct Link Dedicated use cases

Primary use cases include transactional or batch data exchange across business-critical application workloads with high-volume and low-latency real-time access to software services and components across different clouds.

Well suited for continuous high volume real-time data transfers between applications, e.g., system data replication
Direct physical connection provides a robust, reliable, and fast communication to support multiple protocols and complex workload connectivity requirements.

For Direct Link Dedicated use cases, see Customer on-premises facility to IBM Cloud and Customer colocation to IBM Cloud.

For a Power Edge Router (PER) use case for IBM Power System Virtual Server, see Power Edge Router use cases.

Direct Link Connect use cases

Primary use cases include transactional data exchange across business-critical application workloads with moderate to high volume and low latency requirements.
Other use cases include on-demand or scheduled, real-time, near-real-time high volume batch data transfers between applications, such as for analytical processing, archiving, or replication.
Application data exchange is done via RESTful APIs or TCP host/ports for synchronous/real-time calls between systems and components.
Data transfers usually is done using sophisticated data migration and data replication applications.

Connecting to VPC by using Direct Link Connect

Direct Link is a hybrid cloud connectivity service providing secure, private, high-bandwidth connectivity between customer on-premises and IBM Cloud resources. Paired with Power Systems Virtual Servers and IBM Cloud Transit Gateway, Direct Link offers options for high-bandwidth customer demand.

For Direct Link Connect use cases, see Using service provider networks to virtually reach IBM Cloud and Other Cloud Service Provers (CSPs) or enterprises.

For use cases with Power Systems Virtual Server, see Network architecture diagrams.

Transit Gateway use cases

As the number of your Virtual Private Clouds (VPCs) grows, you need an easy way to manage the interconnection between these resources across multiple regions. IBM Cloud Transit Gateway is designed specifically for this purpose.

With IBM Cloud Transit Gateway, you can create single or multiple transit gateways to connect VPCs together. You can also connect your IBM Cloud classic infrastructure to a transit gateway to provide seamless communication with classic infrastructure resources. Any new network that you connect to a transit gateway is then automatically made available to every other network connected to it. This makes it easy to scale your network as it grows.

Transit gateways provide flexibility by allowing you to add networks to local gateways. Networks can be attached to multiple local gateways and a single global gateway, enabling you to keep local traffic on a local gateway.

Connecting two Power Virtual Server environments by using IBM Cloud Transit Gateway

In this deployment topology, a connection through IBM Cloud Transit Gateway is used to provide connectivity between Power virtual server environments at two different data centers. With IBM Cloud Transit Gateway, you can also interconnect your Power Virtual Servers to the IBM Cloud classic and VPC infrastructures, keeping traffic within the IBM Cloud network. Transit Gateway enables you to connect your otherwise disconnected private networks, such as classic, VPC, and Direct Link. In addition, you can establish connection between multiple Power Virtual Server workspaces across different data centers.

The following network architecture allows connectivity between multiple Power Virtual Server locations with high availability (HA) and disaster recovery (DR) solutions.

Transit Gateway deployment scenario — Transit Gateway use case

Key features are as follows:

Access and connectivity between two different Power Virtual Server locations in the same region (for example DAL12 to DAL13) to support HA through replication.
Access and connectivity between two different Power Virtual Server locations in different regions (for example DAL12 to WDC06) to support DR through replication.

With local routing you can only connect PERs in the same region as the Transit Gateway, while PERs in a different region require global routing.

Complete the following steps to implement this scenario:

Create an IBM Cloud Transit Gateway to enable the virtual connections.
Create an IBM Cloud connection with Transit Gateway enabled.
Connect your Power Virtual Servers that are located in data center 1 and data center 2 through the IBM Cloud network by using a transit gateway.

After the transit gateway connection is established, different IBM Cloud networks are connected to each other.

Site-to-site VPN use cases

Primary use cases include administrative remote access to various hosts across the cloud. Other use cases include low to moderate volume transactional or batch data exchange across business-critical application workloads tolerant to higher latency applications.

Direct administrative access to hosts on the cloud is accomplished with jump servers, SSH, remote desktop protocol, and so on.
Application data exchange is accomplished through RESTful APIs or TCP host/ports for synchronous/real-time calls between systems and components.
Data transfer is accomplished using SFTP or simple data migration applications.

Site-to-Site VPN for secure connectivity using a policy-based VPN

Traffic that matches negotiated CIDR ranges passes through a policy-based VPN. You can use policy-based VPN gateways and ingress routing to forward POWER incoming traffic from transit gateways to your on-premises network. VPC 1 adds an on-premises CIDR as the VPC address prefix to allow route propagation.

Client-to-site VPN use cases

Primary use cases include ad hoc or on-demand connectivity for low volume administrative remote access from a client host to hosts on a VPC network. Other use cases include ad hoc or on-demand low volume batch data transfers from a client host to hosts on a VPC network. These connections are tolerant to higher latency.

Direct administrative access to hosts on the cloud is accomplished using jump servers, SSH, remote desktop protocol, and so on.
Data transfer is accomplished using SFTP or simple data migration applications.

Client-to-site VPN for secure connectivity

With Client VPN for VPC (client-to-site VPN) you can securely connect from remote devices to the IBM Cloud network using an OpenVPN client.

To access the resources in VPC1, in your routing table set Accept routes from to VPN server to allow route propagation by the VPN server.

To access resources in the POWER VM, in your routing table, create a VPN server route with the POWER network as the destination using the Translate action. This translates the source IP to the VPN server's private IP, making your VPN client IP invisible to the destination in the POWER network.

Satellite use cases

A Satellite Connector is a lightweight resource that provides secure TLS tunneling from IBM Cloud applications and services to your on-premises resources.
A Satellite Location expands on a Satellite Connector's capabilities by adding the ability for cloud services to be delivered on-premises, such as a managed Red Hat OpenShift on-premises or managed database on-premises. It also allows for communications originating from on-premises to resources inside of IBM Cloud.

Related link: Satellite Connector use cases

Provisioning walk-throughs

Use the walk-throughs to understand the provisioning process for the connectivity method.

Direct Link Dedicated provisioning walk-through

Direct Link Dedicated requires that you install an edge router (CER) to physically connect to the IBM cross-connect router (XCR) in the meet me room (MMR) at the IBM Cloud location. The setup is initiated by requesting an LOA/CFA from IBM to proceed.

You are issued a letter of authorization (LOA) that allows you and your service provider to work with the IBM Cloud site manager to install the CER. The site manager then provides a completion notice indicating that the install happened. This completion notice is approved by the IBM Implementation team for accuracy. After which, the team will ensure IBM side Layer-1 connectivity.

After there is compete Layer-1 connectivity (customer and IBM side), and the direct link is configured on the XCR and cross-connect switch (XCS), the provisioning process is complete. The direct link is now able to establish the boarder gateway protocol (BGP) session between the CER and XCR.

You must have your Direct Link planned and built out before ordering a dedicated direct link to prevent delays. The Dedicated Direct Link physical demarcation is a Patch page Port. It is up to the client to build to the Patch page Port. If this is the first Direct Link order or is a new order into a new region, please allow yourself plenty of time. Depending on where your network's Points Of Presence (PoPs) are, it can take 20 to 40 days to build out to an IBM site.

When all prerequisites are met, the Direct Link Dedicated provisioning process takes approximately 4 weeks to complete. The provisioning process is as follows:

1 day - Read planning considerations and order a Dedicated direct link. For instructions, see Ordering IBM Cloud Direct Link Dedicated.
1 day - You receive a letter of authorization (LOA), which allows your service provider to order and set up the cross-connect for your direct link. You are notified when the LOA becomes available for review on the IBM Cloud console.
Depends on customer - Review the LOA with your service provider for accuracy and accept it. If anything is incorrect, discuss your concern with the IBM implementation team directly through this case.

If the LOA is incorrect, or you have any questions, open a case with IBM Support case, upload your concerns or questions to the case.
Depends on-site provider - Give the approved LOA to your service provider. Work with your service provider to set up the cross-connect within your chosen IBM Cloud location.
Depends on customer - Upload the completion notice received from your service provider on the IBM Cloud console. Ensure that your physical connection is patched down between the device and patch page. Also, check to make sure you're sending light to IBM. For more information, see How do I troubleshoot a Direct Link Dedicated connection during activation? and this completion notice example.
1-2 days - The IBM Implementation team reviews the completion notice to ensure that it aligns with the LOA. If the completion notice is rejected, you are notified through an existing case or via the Direct Link console.
1-4 days - The IBM implementation team checks Layer-1 connectivity between the cross-connect router (XCR) and the Edge router and begins the patch cable installation process to established Layer-1 connectivity.
1-4 days - After the cross-connect completion notice is accepted, the patch cable installation between the IBM Cloud device to the patch page begins.

Some DC sites cannot work on the patch cable installation process until they receive management approval.

After connectivity is established successfully, your gateway moves to Provisioned status. Then, this case is closed. For further assistance with your direct link, contact IBM Support.

Direct Link Connect provisioning walk-through

Use a service provider to quickly establish and deliver connectivity to IBM Cloud locations. A service provider is already connected to the IBM Cloud network via multi-tenant, high-capacity links, also known as a network-to-network interface (NNI). Typically, you can purchase a virtual circuit at this provider, establishing connectivity in a rapid manner because the physical connectivity from IBM to the service provider is already in place.

This offering is ideal for multicloud environments with your service provider's network.

Depending on your service provider, the Direct Link Connect provisioning process takes approximately 3 to 5 business days to complete. Provisioning on the IBM side is completed the same day. The provisioning process is as follows:

IBM Cloud highly recommends that a second, diverse direct link be established to prevent outages, whether unplanned or planned due to maintenance.

1-2 days - Contact your service provider. Determine the location to IBM Cloud by verifying your provider capabilities to reach IBM Cloud over partner interconnects known as NNIs.
1-2 days - Read planning considerations and order Direct Link Connect. For instructions, see Ordering Direct Link Connect.

The IBM side is provisioned immediately after submitting your order in the IBM Cloud console.
After you submit your order, contact your service provider and negotiate connectivity to your environment, whether it is on-premises or in colocation.
Contact your provider for provisioning time - Order a virtual circuit through the service provider. Reference the case ID of the Direct Link Connect request as your Request ID or Authorization ID.
Contact your provider for provisioning time - Configure the BGP parameters on your Edge router for BGP session establishment. After this completes, the BGP status indicates Established.

After connectivity is established successfully, your gateway moves to Provisioned status. Then, this case is closed. For further assistance with your direct link, contact IBM Support.

Transit Gateway provisioning walk-through

Use IBM Cloud Transit Gateway to interconnect IBM Cloud resources and Virtual Private Cloud (VPC) infrastructures worldwide, keeping traffic within the IBM Cloud network.

The provisioning process takes approximately 20-55 minutes to complete. The provisioning process is as follows:

5-10 mins - Review Planning for IBM Cloud Transit Gateway and plan the networks to be connected.
5-20 mins - Create a transit gateway.
5-20 mins - Add desired network connections to the transit gateway. These can be added while the gateway is still provisioning.
5 mins - Verify that you can ping between networks via the transit gateway.

Site-to-site VPN provisioning walk-through

The provisioning process takes approximately 20 minutes to one hour to complete. The provisioning process is as follows:

10 mins - Review planning considerations for VPN gateways and plan for local/remote CIDRs. Also, review VPN gateway limitations and configuration information, such as IKE policies, mode.
10 mins - Create a VPN gateway using the IBM Cloud console or with the CLI and API. Review ACLs and security groups.
5-10 mins, depending on the gateway type - Make sure that your peer device supports NAT traversal and that it is enabled on the peer device.
5 mins - Create a VPN gateway.
5 mins - Create VPN connections.
5 mins - For static, route-based VPNs, select or create a routing table for static routing, then create routes by using the VPN connection type.
10-20 mins, depending on the gateway type - Connect to an on-premises network through a VPN tunnel.
5 mins - Verify that your VPN connection is available by sending ping or data traffic across the tunnel to devices that are on the peer network.

Client-to-site VPN provisioning walk-through

The provisioning process takes approximately 20 minutes to one hour to complete. The provisioning process is as follows:

10 mins - Review planning considerations for VPN servers and decide which VPN client authentication that you want to use: certificate-based, user ID and passcode, or both. For more information, see Setting up client-to-site authentication.
10 mins - For user ID and passcode authentication only, create an IAM access group and grant users the role to connect to the VPN server.
15 mins - Create a Secrets Manager instance and import certificates.
10 mins - Create a VPC. Optionally, configure security groups and ACLs for use with VPN.

Notes:
- For a high available VPN server, create a VPC and two subnets in two different zones.
- For a stand-alone VPN server, create a VPC and one subnet in one zone.
- Ensure your security groups and ACLs allow VPN traffic.
- When creating a new VPC, the default security group that is attached only allows ICMP and SSH communications. Ensure that you add an inbound rule for client-to-site VPN traffic in this security group.
5 mins - For server authentication only, create IAM service-to-service authorization.
5 mins - Create a VPN server and validate status.
5 mins - Create VPN routes.
10 mins - Set up a VPN client environment and connect to the VPN server.

Satellite Connector provisioning walk-through

Satellite Connector provides secure TLS tunneling from IBM Cloud applications and services to your on-premises applications.

Reference

Reference for understanding the key aspects of connectivity and implementation.