Forwarding rules for Traffic Director
Traffic Director uses the forwarding rule to determine the target proxy to which traffic in the mesh is routed.
Each forwarding rule provides a single global IPv4 address for a service. You can use that address to create internal DNS records for your service (for example, by using a Cloud DNS managed private zone). Metadata filters in the forwarding rule specify the criteria for which an xDS-compliant sidecar proxy receives the configuration.
For the Traffic Director control plane, the internal, self-managed, and global forwarding rule routes traffic by IP address, port, and protocol to a target proxy. The target proxy points to a URL map that contains rules that determine the destination of the traffic. The URL map also specifies the default backend service. This backend service specifies a health check and determines the appropriate backend, such as a managed instance group (MIG) that contains virtual machine (VM) instances or a network endpoint group (NEG) that contains Google Kubernetes Engine (GKE) backend Pods.
The following diagram shows how a forwarding rule fits into the Traffic Director architecture.
Forwarding rule properties
A forwarding rule resource contains the following properties that apply to Traffic Director. The forwarding rule handles traffic that matches the destination IP address, protocol, and port number.
0.0.0.0 IP address in a forwarding rule is one of the options when
using Traffic Director. A
0.0.0.0 IP address means any IP address.
With a proxy deployment, a
0.0.0.0IP address lets a proxy match any incoming traffic if no other specific match is found.
With a proxyless deployment, a
0.0.0.0IP address provides a way to specify that an IP address is not required. More details follow about using
0.0.0.0IP addresses with a target gRPC proxy.
The following table describes forwarding rule properties in more detail.
The name of the forwarding rule.
The name must be unique in
this project, from 1 to 63 characters, and match the regular expression:
This means that the first character must be a lowercase letter, and all the following characters must be a dash, lowercase letter, or digit, except the last character, which cannot be a dash.
One of the following:
IP addresses for Traffic Director forwarding rules do not need to correspond to IP address ranges of subnets in the Virtual Private Cloud (VPC) network. For a given VPC network, IP address, and port, you can have only one internal, self-managed forwarding rule.
For example, in the same VPC network, you cannot create
two forwarding rules that use the
A forwarding rule that references a target gRPC proxy with the
A gRPC client that uses the
As a result, Traffic Director uses the
The target proxy that this forwarding rule directs traffic to.
Traffic Director only supports
When you use the Google Cloud console to configure the forwarding rule, the target proxy is configured automatically. When you use the Google Cloud CLI or the API, the target proxy must exist before you create your forwarding rule. You can use more than one forwarding rule with a given proxy.
||✔||The type of protocol that this forwarding rule matches. The only
supported value is
||✔||Specifies how the forwarding rule is used. The valid value for
Traffic Director is
A port or a port range joined by a dash.
Packets of the specified
protocol sent to these ports are forwarded to the appropriate backend.
You can specify a single number of a range—for example,
For a given VPC network, IP address, and port, you can
have only one internal, self-managed forwarding rule. For example, in
the same VPC network, you cannot create two forwarding
rules that use the
With proxyless gRPC services, the port in the forwarding rule is
matched with the port specified in the URI that a gRPC application uses
to connect to a service. If a port is not specified in the URI, then
Specifies the VPC network where the Google Cloud VMs running Envoy proxies are located.
The Envoy proxies read the
Traffic Director configuration that you define for the same network
where the proxies are deployed. You can use the VPC
Traffic Director supports load balancing for clients only within the Google Cloud network. You specify the network name in the forwarding rule. VPC Network Peering isn't supported.
Add a global forwarding rule
To learn how to configure a forwarding rule within the overall Traffic Director setup, see the following:
- Set up Traffic Director for Compute Engine VMs with automatic Envoy deployment
- Set up Traffic Director for Compute Engine VMs with manual Envoy deployment
- Set up Traffic Director for GKE Pods with automatic Envoy injection
- Set up Traffic Director for GKE Pods with manual Envoy injection
- Set up Traffic Director for Compute Engine VMs and proxyless gRPC services
- Set up Traffic Director for GKE Pods and proxyless gRPC services
- To use metadata filters to control which sidecar proxies receive the
configuration attached to the forwarding rule, see
Setting up config filtering based on
- To route traffic, see Traffic Director routing rule maps overview.
- To learn more about Traffic Director, see the Traffic Director overview.