Routing TCP traffic with Traffic Director

This guide demonstrates how you can use Traffic Director to route traffic to services that handle TCP traffic, including databases, VOIP services, and management platforms, which expect to receive TCP traffic on specific ports or port ranges.

This guide will show you how to:

Set up a service that represents a collection of identical backends/endpoints, which handle TCP requests from clients.
Set up a routing rule map so that Envoy proxies configured by Traffic Director can send TCP requests. The following diagrams show how TCP routing works for VMs and NEGs, respectively.

Compute Engine API resources for VMs (click to enlarge) — Setting up Traffic Director for TCP, Compute Engine backends (click to enlarge)

Compute Engine API resources for NEGs (click to enlarge) — Setting up Traffic Director for TCP, NEG backends (click to enlarge)

Preparation

This tutorial builds on the Envoy for service mesh setup guide, and assumes that you already have a basic understanding of how Traffic Director works.
The tutorial focuses on aspects of Traffic Director setup that are different when configuring your services and routing for TCP traffic.
We assume that you already have already set up a managed instance group or network endpoint group.

Configuring load balancing resources

Use the following steps to configure the load balancing resources.

Create a TCP health check

Create a health check.

Setup with VMs

If you are configuring managed instance groups, use the following command to create a global health check, replacing the PORT field.

gcloud compute health-checks create tcp td-vm-health-check \
    --global \
    --port=PORT

Setup with NEGs

If you are configuring network endpoint groups, use the following commands to create a health check and to create a firewall rule to allow the health checker IP address ranges.

gcloud compute health-checks create tcp td-gke-health-check \
    --use-serving-port

Create a firewall rule for your health check. This rule enables health checks from Google Cloud's health checkers to reach your backends. See health checks for more information on creating firewall rules for health checks.

gcloud compute firewall-rules create fw-allow-health-checks \
  --action ALLOW \
  --direction INGRESS \
  --source-ranges 35.191.0.0/16,130.211.0.0/22 \
  --target-tags TAGS \
  --rules tcp:80

See the gcloud reference docs for additional information (including guidance for TAGS).

Creating a backend service for your TCP backends

The backend service setup for TCP with Traffic Director differs slightly from the setup for HTTP. The following steps capture those differences.

Setup with VMs

If you are configuring managed instance groups, use the following command to create a backend service and add the health check.

gcloud compute backend-services create td-vm-service \
   --global \
   --load-balancing-scheme=INTERNAL_SELF_MANAGED \
   --health-checks=td-vm-health-check \
   --protocol=TCP \
   --global-health-checks

The final step for setting up your backend service is to add your backend group. Because this step is standard Traffic Director setup (in other words, nothing specific for TCP-based services) it is not shown here. Please refer to the setup guide for more information.

Setup with NEGs

If you are configuring network endpoint groups, use the following commands to create a backend service and add the health check.

Create the backend service and associate the health check with the backend service.

gcloud compute backend-services create td-gke-service \
  --global \
  --health-checks td-gke-health-check \
  --protocol=TCP \
  --load-balancing-scheme INTERNAL_SELF_MANAGED

Set up routing for your TCP-based backend service

In this section, you create a global target TCP proxy, and global forwarding rule. These resources enable your applications to send traffic to the backends with your newly-created backend services.

Keep the following in mind:

Your forwarding rule must have load balancing scheme INTERNAL_SELF_MANAGED
The VIP and PORT that you configure in the forwarding rule are the VIP and PORT that your applications will use when sending traffic to your TCP services. You can choose the VIP from one of your subnets. Traffic Director uses this VIP and PORT to match client requests to a particular backend service.
- See Service Discovery for information on how client requests are matched to backend services.

Use the following command to create the target TCP proxy, replacing BACKEND_SERVICE with the name of the backend service created in the previous step. In the following example we use td-tcp-proxy as the name for the target TCP proxy, but you can choose a name that suits your needs.
```
gcloud compute target-tcp-proxies create td-tcp-proxy \
--backend-service=BACKEND_SERVICE
```
Note: Each service that requires a different VIP address must use a different forwarding rule.

Create the forwarding rule. The forwarding rule specifies the VIP and Port that are used when matching client requests to a particular backend service. See the gcloud reference for additional info about fields.

gcloud compute forwarding-rules create td-tcp-forwarding-rule \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --address=VIP\
    --target-tcp-proxy=td-tcp-proxy \
    --ports PORT \
    --network default

At this point, Traffic Director is configured to load balance traffic for the VIP specified in the forwarding rule across your backends.

Troubleshooting

If your applications are attempting to send requests to your TCP-based services:

Confirm that the TCP health check port matches the port on which the TCP application expects to receive health check traffic.
Confirm that the port name of the backend service matches what is specified in the instance group.