IBM Cloud Docs
Architecture pattern for using Transit Gateway with a vCenter Server with NSX-T instance

Architecture pattern for using Transit Gateway with a vCenter Server with NSX-T instance

This architecture pattern presents hybrid cloud connectivity by using IBM Cloud® Transit Gateway. This solution is applicable for NSX-T based vCenter Server instance, which is provisioned in IBM Cloud classic infrastructure. This pattern requires a gateway appliance or gateway cluster with Juniper vSRX or other third-party device, which supports GRE. In this solution, GRE tunnel is established between this device and Transit GW Router in a specific Zone. NSX-T T0 advertises routes through vSRX (or other device) to Transit Gateway.

Deploying Transit Gateway with vCenter Server and NSX-T

The following diagram presents an overview for an architecture pattern for deploying Transit Gateway with vCenter Server and NSX-T.

Transit Gateway with vCenter Server and NSX-T
Figure 1. Transit Gateway with vCenter Server and NSX-T

The following list summarizes the architecture pattern deployment:

  1. vCenter Server instance is deployed at IBM Cloud Classic Infrastructure. Two IBM Cloud private VLANs and one IBM Cloud Public VLAN (optional) is deployed. Each of them hosts multiple subnets. You can see the details through IBM Cloud for VMware Solutions portal.
  2. NSX-T T0 is deployed with two interfaces - private and public (optional). If you opt for a public, this interface is attached to your Public VLAN and has direct internet access. Your T0 private interface is attached to the Private VLAN and it is using IBM Cloud Portable Private IP.
  3. vSRX (or other device) running on the gateway cluster or gateway appliance is deployed to your Classic Infrastructure. Configure your vCenter Server instance private primary VLAN to be routed through the vSRX or Gateway Appliance. Also, establish routing between your NSX-T T0 and vSRX, such as BGP.
  4. Order an IBM Cloud Transit Gateway at your IBM Cloud data center or zone location and add your classic network as a connection.
  5. Create a GRE connection on your transit gateway by using your classic network as the transport for your GRE tunnel. For the remote gateway IP, select your vSRX or gateway appliance private IP. For the Local gateway IP, you can select an IP address to be advertised through your Classic Network to the vSRX or Gateway Appliance. Ensure that your vSRX or Gateway Appliance has a route to this IP. For Local or Remote tunnel IP, you can select the IP addresses for the GRE tunnel IP addresses.
  6. Your vSRX or Edge Gateway Appliance and Transit Gateway must exchange routes through BGP. TGW can choose a BGP ASN for your NSX-T networks, or you can enter your own ASN when you create the GRE connection in TGW. You must configure your T0 to advertise your preferred NSX-T overlay networks to the Transit Gateway. Ensure that you do not advertise routes that collide with your Classic Private Subnets. Also, ensure that you advertise the networks learned from your NSX-T T0 to the Transit Gateway.
  7. You can add other connections (VPC or other Classic) to the Transit Gateway. Your VPC IP address allocation design must not overlap with the attached Classic network nor with the NSX-T overlay networks.
  8. You can add Direct Link connections to the transit gateway for on-premises Connectivity. Transit Gateway advertises the attached routes of VPC, classic network, and GRE tunnel to the attached Direct Link.

Considerations

When you design or deploy this architecture pattern, you must consider the following steps:

  • Direct Link can be attached as a connection to the Transit Gateway.
  • Transit gateway GRE tunnels support traffic flows:
    • From GRE to VPC and from VPC to GRE, and
    • From GRE to Direct Link and from Direct Link to GRE.
  • Plan your AS numbering before you order the GRE tunnels to Transit Gateway.
  • To speed up recovery in failure situations, you can tune BGP keepalive and hold-time values at your end of the GRE tunnel. These values are the main mechanisms that the Transit Gateway's BGP uses to ensure that its BGP neighbors are still alive through the GRE tunnel. Transit gateway router provides its default keepalive and hold-time values for the BGP session inside the GRE tunnel, but you can provide smaller timer values on your side of the GRE tunnel.

When a BGP connection is established with the local routing device, a peer sends an open message that contains a hold-time value. If the router does not receive successive BGP messages, such as keepalive or update within the period that is specified in hold-time the BGP connection is closed. The BGP hold-time is three times the interval at which keepalive messages are sent, and hold-time is the maximum number of seconds allowed to elapse between successive keepalive messages that BGP receives from a peer. BGP on the local routing device uses the smaller of either the local hold-time value or the peer’s hold-time value as hold-time for the BGP connection between the two peers.

Bidirectional Forwarding Detection (BFD) is not supported by Transit gateway's GRE tunnels.

In vSRX, the default hold-time is 90 seconds, which means that the default frequency for keepalive messages is 30 seconds. For more information, see precision-timers and hold-time (Protocols BGP).