FAQs for IBM Cloud Transit Gateway
These frequently asked questions can help you when working with the IBM Cloud® Transit Gateway.
What are the differences between IBM Cloud Transit Gateway and IBM Cloud Direct Link?
IBM Cloud Direct Link provides connectivity from an external source into a customer's IBM Cloud private network. IBM Cloud Transit Gateway provides connectivity between resources within a customer's IBM Cloud private network.
Where can I find Transit Gateway pricing?
You can estimate the cost of a transit gateway using the cost estimator on the provisioning page for IBM Cloud Transit Gateway Transit Gateway. For example, from the IBM Cloud console, click
the Menu icon 
from the upper left and select Interconnectivity > Transit Gateway. Then, click Create transit gateway to open the provisioning page.
If I connect a classic connection to a transit gateway provisioned with local routing, does that mean I can only communicate with classic infrastructure resources that are in the same location as the transit gateway?
A classic connection allows you to communicate with all of your global classic infrastructure resources across MZRs, even if it is connected to a transit gateway provisioned with local routing.
The routing option that you choose for a transit gateway only determines what VPCs you can connect to it. Local routing restricts you to connecting VPCs in the same MZR as the transit gateway, while global routing allows you to connect any VPC across the MZRs. Select the routing option that is right for your applications - pricing is changed accordingly.
Can I create more than one transit gateway in my account?
You can create more than one transit gateway in your account. Each transit gateway (and its connections) are logically isolated from your other transit gateways.
Can I create more than two connections for a given transit gateway?
You can connect multiple VPCs in the same region to a single transit gateway with the local routing option, and connect them across regions by using global routing. Keep in mind that all of a transit gateway's network connections are interconnected, so carefully consider all resources that you want to connect. Make sure each connection receives a unique name in the gateway, and that you choose the appropriate routing type (local or global) based on the location of the connections.
Can I connect to a VPC or classic infrastructure in another IBM Cloud account?
You can connect to both a VPC or classic infrastructure in another IBM Cloud account by providing the appropriate connection information when adding a connection to your transit gateway. The account containing the VPC or classic infrastructure is then able to view the gateway and all of its connections, and must choose to opt-in to allow account-to-account interconnectivity for that VPC. For more information, see Adding a cross-account connection.
How many connection requests can I make from one account to VPCs in other IBM Cloud accounts?
Each gateway is only permitted to have ten outstanding requests for a cross-account connection.
I connected a VPC to one transit gateway. Can I connect that VPC to a second transit gateway?
You can connect a VPC to multiple local transit gateways and a single global gateway.
I connected a classic connection to one transit gateway. Can I connect the classic connection to a second transit gateway?
You can connect a classic connection to multiple local transit gateways and a single global transit gateway.
Can I connect a direct link to both a VPC and a transit gateway simultaneously?
No, you must choose to connect to a direct resource (VPC or classic infrastructure), or bind your direct link to one or more local transit gateways, or one global gateway. Your on-premises network can then access IBM Cloud resources connected through the transit gateways.
I can only provision a transit gateway in a certain set of locations on the provisioning page. Does that mean that the VPC I want to connect must be located in one of those locations?
By enabling global routing, you can connect VPCs located in different MZRs, regardless of the set of locations that you can provision your transit gateway in.
What are the service limits that I must keep in mind while using IBM Cloud Transit Gateway?
For more information, see Service limits.
Classic access VPCs cannot be attached to a transit gateway. How can I connect and access classic resources in those VPCs?
Although classic-access VPCs cannot be attached to a transit gateway, access to classic resources and classic-access VPC resources can be achieved by adding the classic infrastructure connection to a transit gateway. For more information, see Classic infrastructure connection considerations.
How can "VPC peering" be achieved on IBM Cloud?
IBM Cloud Transit Gateway can be used to connect multiple VPCs to each other. As such, connecting/peering two VPCs is just a part of the functionality that the transit gateway service offers. IBM Cloud does not provide a standalone VPC peering service or capability.
Can I connect a VPN or a direct link to a transit gateway?
IBM Cloud Direct Link can be connected to either a local or global transit gateway.
Currently, you cannot connect a VPN to a transit gateway.
Can I create a global transit network using the IBM Cloud Transit Gateway?
IBM Cloud Transit Gateway enables standard IP routing between networks (for example, global VPCs) that are connected to it. You can add additional functionality by configuring IBM or third-party virtual network functions, such as VPN, NAT, and firewalls, within one or more of the interconnected networks (for instance, using the "Transit VPC" concept).
How can I guarantee one of my clients is not going to impact the others?
Capacity management handles the overall available capacity on the transit gateway and is subject to our weekly capacity management review. When the device reaches roughly a 50% load, we augment the connectivity to the device.
What scalability options do I have for my transit gateway? Does it manage itself? How do I know if it's reaching maximum capacity?
The IBM Cloud infrastructure manages all transit gateways. There are no scalability options available.
How do you prevent Distributed Denial of Service (DDoS) attacks? What restrictions do you have in place?
Neither third-parties nor the internet can see your transit gateway traffic. As no critical information, such as IP router addresses, is open to anyone but you, DDoS attacks cannot bring down the network. In addition, a typical Multi-protocol Label Switching service (MPLS) uses packet filtering and applies access control lists (ACLs) to limit access. Only the ports with routing protocols from a specific area of the network can access the information.
How does my transit gateway handle encryption for connectivity between VPCs?
IBM Cloud Transit Gateway does not perform encryption; it only provides connectivity. Encryption between VPCs is your own responsibility.
It is an RFC-2547-based platform where the core network and network address are 100% concealed.
What are the tools for monitoring the consumption of resources associated with the service, as well as the costs and the quality of the service?
IBM Cloud Transit Gateway is integrated into the IBM Cloud usage dashboard, which provides a summary of estimated charges for all services and resources that are used per month in your organizations. This includes the number of connections and the amount of traffic flowing across your transit gateways. IBM Cloud Transit Gateway usage is billed and reported as part of the IBM Cloud invoice process.
Can I generate a route report for a transit gateway?
Yes, you can. For detailed instructions, see IBM Cloud Transit Gateway route reports.
Can I interconnect VPCs using a transit gateway?
You can create a single transit gateway or multiple transit gateways to interconnect more than one IBM Cloud VPCs. You can also connect your IBM Cloud classic infrastructure to a transit gateway to provide seamless communication with classic infrastructure resources. For more information, refer to Interconnecting VPCs.
In a Highly Available (HA) configuration, how long after the failover of the primary GRE tunnel does the routing device wait before declaring it inactive?
This time, by default, is set as 5 minutes (300 seconds), and defined by the configuration statement stale-routes-time. The stale-routes-time statement allows you to set the length of time the routing device waits to
receive messages from restarting neighbors before declaring them inactive. This means, in the case of a GRE HA failover to a second GRE tunnel, the traffic takes 5 minutes to be reflected by the second tunnel.