Planning for IBM Cloud Transit Gateway

General considerations

All prefixes of a VPC and all subnets of a classic network will connect to the transit gateway, so it's important that they do not overlap. When creating VPCs that are intended to connect to a transit gateway, make sure to create the VPCs with non-overlapping VPC prefixes.

• IBM Cloud Transit Gateway supports provisioning transit gateways in the regions listed in IBM Cloud Transit Gateway locations.

• Create your transit gateway in a location that makes sense for your workload. For example, if you are connecting two VPCs in the us-south (Dallas) region and one VPC in the eu-de (Frankfurt) region, creating your gateway in us-south region would be the most efficient for your workload.

• You cannot connect a classic access VPC directly to a transit gateway. To connect the classic resources, use the IBM Cloud classic infrastructure connection, and then all the resources in your classic access VPC are automatically connected.

• A transit gateway requires at least two connections before network traffic can flow over the transit gateway. Transit gateways that have less than two connections for 45 days or more are subject to be reclaimed (suspended, then deleted after 30 days).

• You can connect a VPC, Direct Link, or classic infrastructure to multiple local gateways and a single global gateway.

• Transit gateways and their connections can take several minutes after provisioning before they are available.

• Be descriptive when naming your transit gateway connections. When connecting to resources across accounts, you must specify a connection name. When connecting to resources in the same account as the transit gateway, the VPC name or the word 'classic' is the default selection and can be modified.

• IBM Cloud Transit Gateway is a multi-tenant application, where a single instance of the software, and its supporting infrastructure, serves multiple customers. As a result, monitoring your bandwidth use is important. If you use too much bandwidth, your transit gateway instance may be suspended. If you suspect this is the case, check the transit gateway instance connection status to see if it is in a Suspended state. If so, contact support to reinstate it.

• The following ASNs are blocked on Transit Gateway GRE tunnels and Direct Link connections. Avoid using these ASNs on appliances so that they are not included on the advertised routes in the AS path. Having these ASNs included prevent networks from working properly.

  0, 13884, 36351, 64512, 64513, 65100, 65200–‍65234, 65402‍–‍65433, 65500, and 4201065000‍–‍4201065999

Classic infrastructure connection considerations

• To use a transit gateway to connect your VPCs to your IBM Cloud classic infrastructure, you must enable your classic account for virtual routing and forwarding (VRF) and link it to your IBM Cloud account. For information on enabling your account for VRF, see Enabling VRF and service endpoints.

• When you connect a VPC and the classic infrastructure to a transit gateway, all prefixes in the VPC become visible to the classic infrastructure VRF, which uses IP addresses in the 10.0.0.0/8 space. To ensure successful connectivity with the classic infrastructure, do not use prefixes in your VPCs that overlap with the 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15, and 10.254.0.0/16 blocks. Also, don't use addresses from your classic infrastructure subnets. To view a list of your classic infrastructure subnets, see View all subnets.

• Classic virtual server instances can have both a private (eth0) and a public (eth1) network interface. Currently, the routing tables for these interfaces point the default gateway to the public interface (eth1). You might have to add routing entries to route the subnets from other VPCs through the private interface.

• All of your IBM Cloud classic infrastructure networks across MZRs are accessible through this connection, regardless of the location of the transit gateway or the routing type specified.

• Classic infrastructure resources located in these data centers connect through a transit gateway to VPC resources.

• When classic infrastructure is connected to a transit gateway, it also includes any "Classic Access VPCs" attached to the account, because the subnets for these VPCs are associated with the classic infrastructure VRF. This is the only way to connect a transit gateway to a Classic Access VPC: by connecting the entire classic infrastructure to the transit gateway (instead of the specific Classic Access VPCs).

• Classic connections residing in the same data center are unable to communicate with each other if they are in a different region than the transit gateway.

Generic Routing Encapsulation (GRE) connection considerations

When configuring a GRE tunnel, you must specify an availability zone in which to create the tunnel. Because of this, if for some reason that zone becomes unavailable, any network connected through a GRE tunnel on that zone is unreachable. To configure a highly available GRE tunnel, you must create a GRE tunnel in multiple zones, connecting the same endpoints.

GRE connections require the use of a BGP service between GRE tunnel IP addresses. The transit gateway configures a BGP service on the tunnel connection, before connecting to the other tunnel endpoint. Then, once the BGP protocol exchanges routes between the connected endpoint and the transit gateway, the GRE tunnel becomes the data path for the routed traffic.

GRE Tunnel routes are learned directly on BGP sessions established over the tunnel. For this reason, prefix filtering is not enabled for these connections.

The number of GRE tunnels connected to a transit gateway is quota limited. The default quota is 12.

Legacy GRE tunnel considerations:

• Classic routes are not advertised through a traditional GRE tunnel.
• Legacy GRE tunnels cannot communicate through other GRE tunnels on the same transit gateway.
• Legacy GRE tunnels require a classic connection on the transit gateway before creation. As a result, all classic subnets will be advertised to all connections attached to the transit gateway, as well as any other of the connection's subnets on the classic network.

Unbound GRE tunnel considerations:

• Classic routes are advertised through an unbound GRE tunnel.
• Unbound GRE tunnels can communicate through other unbound GRE tunnels connected to the same transit gateway in the same availability zone.
• Unbound GRE tunnels cannot communicate with other unbound GRE tunnels on the same transit gateway if they are in a different availability zone. Unbound GRE tunnels in this scenario cannot be relied on for network isolation.

If you require network isolation, consider using separate transit gateways.

• Unbound GRE tunnels do not require a classic connection on the transit gateway. Classic network subnets will not be advertised to the connections on the transit gateway (or vice versa).
• The default number of unique base networks that can be targeted by unbound GRE tunnel connections is limited to 5. You can open an IBM Support case if you need these service limits expanded.

For more information and a use case example, refer to Connect networks using a High Availability GRE tunnel.

Direct Link connection consideration

You can create Direct Link connections to a transit gateway to allow on-premises networks to connect to other networks in IBM Cloud. After the direct link connects to the transit gateway, the on-premises network receives access to all other transit gateway connections. Likewise, all other networks connected to the transit gateway have access to the on-premises network. Direct Link connections follow the same process for physical or virtual cross connections as the standard Direct Link offering. After the connection is deleted from a transit gateway, the transit gateway operates as if it was never connected to a direct link.

The same network subnet considerations for transit gateway connections also apply to Direct Link connections. To ensure successful connectivity, do not use prefixes in your Direct Link connected network that overlap with other connections.

Power Virtual Server connection considerations

You can connect a Power Virtual Server instance to a transit gateway. This allows you to directly attach the Power Virtual Server to a downstream transit gateway. After the Power Virtual Server is connected to the transit gateway, your Power Virtual Server service instance then has have access to all downstream transit gateway resources and services. Likewise, all downstream networks connected to the transit gateway will have access to the Power Virtual Server instance.

Power Virtual Server connections can use Local or Global routing. However, only Power Virtual Server instances in the same region as the transit gateway can use local routing. Also, a Power Virtual Server instance can be connected to multiple transit gateways with local routing, but only one transit gateway with global routing. Downstream services will honor route preference based on the transit gateway type.

The same network subnet considerations for transit gateway connections also apply to Power Virtual Server connections. To ensure successful connectivity, do not use prefixes in your Power Virtual Server instance that overlap with other connections. Note that Transit Gateway provides prefix filtering to limit the prefixes being exposed, as well as a routing table report to see any overlaps after the connection is created.

VPC connection consideration

IBM Cloud VPC permits the use of RFC-1918 and IANA-registered IPv4 address space, privately within your VPC, with some exceptions in the IANA special-purpose ranges, and select ranges assigned to IBM Cloud services. When using IANA-registered ranges within your enterprise, and within VPCs in conjunction with IBM Cloud Transit Gateway, custom routes must be installed in each zone. For more information, see Routing considerations for IANA-registered IP assignments.

VPC interconnection consideration

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.

Routing considerations

• All connections to a transit gateway are connected to each other, so carefully consider all resources that you want to interconnect before deciding whether local or global routing is right for each gateway.

  Traffic from either routing option does not leave the private IBM Cloud network and is optimized for performance.

• If you plan to use your gateway to connect VPCs in the same multi-zone region (MZR), use local routing to provide connectivity to all accessible resources within the same MZR; for example, us-south (Dallas).

  

• If you plan to use your transit gateways to connect VPCs locally and between different MZRs, use local gateways for VPCs in the same MZR, and a global gateway for VPCs across MZRs. You can use the example that follows a Highly Available (HA) scenario as well. All data in VPCs A and B can be replicated to VPCs C and D. If there is an issue in the US South region, connections reroute to US East.

  

  Regardless of the routing type specified, IBM Cloud Transit Gateway can connect to classic infrastructure networks located in any MZR. To achieve this, simply add the classic connection to your transit gateway.

• You can edit a gateway's routing type after it is provisioned. However, to change the routing type from global to local, you must first remove any global connections (that is, connections to resources that are not in the same location as the gateway). Note that connections to the IBM Cloud classic infrastructure are always considered local.

• When changing from Local to Global routing, you will be charged for all associated global connections. There is no impact to the network traffic when the routing type is changed.

Route report considerations

• 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. For more information, see Addressing route conflicts.
• After a new virtual connection (VPC, Classic infrastructure, or Direct Link) reaches Active state, allow 5 minutes for the routes to be learned by your transit gateway. Generating a route report before all routes are learned results in a partial route report.
• If a connection exposes a route of 0.0.0.0/0, that route is ignored when computing overlapping prefixes.
• Only one report per gateway is available at any time. If you generate a new report, the old report is deleted.
• Older route reports might be inaccurate after you add or remove a connection. As a result, if you update routes within those connections, it is recommended that you generate a new route report.
• If one or more routes are denied by prefix filters, those routes do not appear in the route report.

Service limits

Keep in mind the following service limits while using IBM Cloud Transit Gateway.

You can open an IBM Support case if you need your service limits expanded.